HP NNMi 9.00 Online Help: Help for Administrators

HP Network Node Manager i Software
For the Windows®, HP-UX, Linux, and Solaris operating systems
Software Version: NNMi 9.00
Online Help: Help for Administrators
Document Release Date: March 2010
Software Release Date: March 2010
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Disclaimer for PDF Version of Online Help
Disclaimer for PDF Version of Online Help
This document is a PDF version of the online help. This PDF file is provided so you can easily print
multiple topics from the help information or read the online help in PDF format.
Note: Some topics do not convert properly to PDF format. You may encounter formatting problems or
unreadable text in certain document locations. Those problem topics can be successfully printed
from within the online help.
Page 2 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Legal Notices
Legal Notices
Warranty
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
The information contained herein is subject to change without notice.
Restricted Rights Legend
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent
with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard
commercial license.
Copyright Notice
© Copyright 2008–2010 Hewlett-Packard Development Company, L.P.
Trademark Notices
Acrobat® is a trademark of Adobe Systems Incorporated.
HP-UX Release 10.20 and later and HP-UX Release 11.00 and later (in both 32 and 64-bit configurations)
on all HP 9000 computers are Open Group UNIX 95 branded products.
Java™ is a US trademark of Sun Microsystems, Inc.
Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
Oracle Technology — Notice of Restricted Rights
Programs delivered subject to the DOD FAR Supplement are ‘commercial computer software’ and use,
duplication, and disclosure of the programs, including documentation, shall be subject to the licensing
restrictions set forth in the applicable Oracle license agreement. Otherwise, programs delivered subject to
the Federal Acquisition Regulations are ‘restricted computer software’ and use, duplication, and disclosure
of the programs, including documentation, shall be subject to the restrictions in FAR 52.227-19,
Commercial Computer Software-Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway,
Redwood City, CA 94065.
For the full Oracle license text, see the license-agreements directory on the NNMi product DVD.
Acknowledgements
This product includes software developed by the Apache Software Foundation.
(http://www.apache.org)
This product includes software developed by the Indiana University Extreme! Lab.
(http://www.extreme.indiana.edu)
This product includes software developed by The Legion of The Bouncy Castle.
(http://www.bouncycastle.org)
This product contains software developed by Trantor Standard Systems Inc.
(http://www.trantor.ca)
Page 3 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Table of Contents
Disclaimer for PDF Version of Online Help
2
Legal Notices
3
Table of Contents
4
Introduction for NNMi Administrators
20
Administrator Tools in the Console
22
Quick Start Configuration Wizard
23
Configuration Workspaces
23
Enable or Disable Configurations
26
Lookup Fields
27
Use the Quick Find Window
28
Use Autocomplete
28
Create a Configuration Object Instance Using the Form Toolbar
29
Delete One or More Objects
29
Actions Provided by NNMi
30
NNMi Processes and Services
44
About Each NNMi Process
45
Verify that NNMi Processes Are Running
45
Stop or Start an NNMi Process
45
About Each NNMi Service
46
Verify that NNMi Services are Running
47
Stop or Start NNMi Services
49
Introduction to IPv6 in NNMi-Advanced
50
Use NNMi Help Anywhere, Anytime
51
Connecting Multiple NNMi Management Servers (NNMi Advanced)
52
Regional Manager: Create a Forwarding Filter (Limit the available Node information)
53
Global Manager: Connect to a Regional Manager
55
Global Manager: Configure the Regional Manager Connection
56
Disconnect Communication with a Regional Manager
59
Troubleshoot Global Network Management
61
Clock Synchronization Issues (SSO / Global Network Management)
61
Determine the State of the Connection to a Regional Manager
62
Check the Health of Global Managers and Regional Managers
63
Page 4 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Error Messages About Regional Managers (NNMi Advanced)
Configuring Communication Protocol
Configure Default SNMP and ICMP Protocol Settings
64
66
67
Timeout / Retry Behavior Example for SNMP
72
Timeout / Retry Behavior Example for ICMP
73
Configure Default Community Strings (SNMPv1 or SNMPv2c)
Default Read Community String Form
73
75
Configure Default SNMPv3 Settings
76
Default SNMPv3 Settings form
77
Configure the Default Device Credentials (NNM iSPI NET)
78
Configure Regions (Communication Settings)
79
Communication Region Form
80
Configure Address Ranges for Regions
86
Configure Hostname Filters for Regions
89
Configure SNMPv1/v2 Community Strings for Regions
90
Configure SNMPv3 Settings for Regions
92
Communication Region SNMPv3 Settings form
Configure Credential Settings for Regions (NNM iSPI NET)
Configure Specific Nodes (Communication Settings)
Specific Node Settings Form (Communication Settings)
93
94
95
96
Configure SNMPv1/v2 Community Strings for a Specific Node
102
Configure SNMPv3 Settings for a Specific Node
104
Configure Credential Settings for a Specific Node (NNM iSPI NET)
104
Load Specific Node Settings from a File
106
Troubleshooting Communication Settings
107
Verify That All Nodes Support SNMP
108
Verify a Node's Communication Settings
108
Identify Unexpected Overrides of Communication Settings
109
Resolve Authentication Errors
110
Discovering Your Network
How Spiral Discovery Works
112
113
Rediscovery Intervals
115
Discovery Node Name Choices
115
Node Name Decision Tree
117
Discovery Seeds (as a starting point)
Page 5 of 1087
118
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Ping Sweep (as a starting point)
118
Auto-Discovery Rules
119
Filters to Exclude Certain IP Addresses from Discovery
120
Filters to Exclude Certain Interfaces from Discovery
120
Subnet Connection Rules
121
Device Profiles and Discovery
123
Prerequisites for Discovery
123
SNMP Prerequisites
123
Well-Configured DNS Prerequisite
124
Use nslookup to Verify DNS Server Configurations
124
Exclude Problem Devices from nmlookup
125
IPv6 Addresses Prerequisite (NNMi Advanced)
125
Determine Your Approach to Discovery
126
Do Not Use Auto-Discovery Rules
127
Routers and Switches Discovered
127
All SNMP Devices Discovered
128
Everything Discovered
129
All Devices from a Specific Vendor Discovered
131
Limit Sources of Neighbor Information
132
Exclude Problem IP Addresses from Discovery
133
Exclude Problem Interfaces from Discovery
133
Specific System Object IDs Not Discovered
133
Configure Device Profiles
134
Configure Discovery
135
Adjust the Rediscovery Interval
137
Configure Ping Sweep Global Settings
137
Configure the Node Name Strategy
138
Configure Auto-Discovery Rules
139
Configure Basic Settings for the Auto-Discovery Rule
141
IP Address Ranges for Auto-Discovery
143
SNMP System Object ID Ranges for Discovery
148
Configure Subnet Connection Rules
Subnet Connection Rules Provided by NNMi
150
152
Configure an Excluded IP Addresses Filter
153
Configure an Excluded Interfaces Filter
155
Page 6 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Specify Discovery Seeds: Initial Routers or Specific Nodes to be Discovered
156
In the Console, Configure Discovery Seeds
157
With a Seed File, Add Multiple Discovery Seeds
160
From the Command Line, Add Discovery Seeds
162
Examine Discovery Results
164
Check Initial Progress of Discovery
164
Node Discovery State Check
164
Verify Success of Discovery Seeds
165
Discovery Seed Results
165
Examine Discovery Inventory
167
Examine Layer 2 Discovery Results
168
Examine Layer 3 Discovery Results
168
Keep Your Topology Accurate
169
Delete Nodes
170
Delete Discovery Seeds
171
Detect Interface Changes (renumbering issues)
172
Add or Delete a Layer 2 Connection
174
Start Discovery On-Demand
177
Creating Groups of Nodes or Interfaces
Create Node Groups
In the Console, Create Node Groups
Specify Node Group Additional Filters
179
179
180
181
Node Groups of IPv4 or IPv6 Addresses
188
Guidelines for Creating Additional Filters for Node Groups
189
Add Boolean Operators in the Additional Filters Editor
191
In a CSV File, Define Node Groups
Create Interface Groups
Specify Interface Group Additional Filters
194
195
196
Interface Groups of IPv4 or IPv6 Addresses
204
Guidelines for Creating Additional Filters for Interface Groups
205
Add New IfTypes (Interface Types) to the List
Node Groups Provided by NNMi
206
207
Node Groups As Predefined View Filters
207
Island Node Groups
209
Interface Groups Provided by NNMi
Page 7 of 1087
210
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Add Custom Attributes to a Node or Interface Object
211
Add Custom Attributes to Multiple Nodes or Interfaces
212
Monitoring Network Health
213
About the State Poller
213
The NNMi Causal Engine and Monitoring
214
Configure Monitoring Behavior
214
Set Global Monitoring
215
Set Default Monitoring
217
Configure Interface Monitoring
221
Configure Threshold Monitoring for Interfaces (HP Network Node Manager iSPI
Performance for Metrics Software)
226
Determine Reasonable Threshold Settings (HP Network Node Manager iSPI Performance
for Metrics Software)
229
Examples of Threshold Monitoring (HP Network Node Manager iSPI Performance for
Metrics Software)
Configure Node Monitoring
230
232
Configure Threshold Monitoring for Nodes (HP Network Node Manager iSPI Performance
for Metrics Software)
238
Configure Node Group Status
241
Configure Percentage Values for the Target Status
241
Node Group Status Settings Form
242
Monitor Router Redundancy Groups (NNMi Advanced)
244
Current Health of the State Poller Service
244
Verify Monitoring Configuration Settings
244
Monitor Status Distribution for Network Objects
247
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
248
View the Management Mode for Objects in Your Network
249
Unmanaged Nodes View
250
Unmanaged Interfaces View
251
Unmananaged Addresses View
251
Unmanaged Cards View
251
Unmanaged Node Components View
252
How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address
252
How the NNMi Administrators Change a Management Mode
254
Understand the Effects of Setting the Management Mode to Not Managed or Out of Service
255
Configuring the NNMi User Interface
257
Page 8 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Controlling Access to NNMi
260
Configure Sign-In Access
260
Roles Provided in NNMi
261
Determine which NNMi Role to Assign
261
Control Menu Access
262
Control Access with NNMi Accounts
Change Password, Name, or Role Assignment
Control Access Using Both Directory Service and NNMi
Change Role Assignment for a Directory Service User Name
Control Access with a Directory Service
Disable a User's Access to NNMi (User Principals)
264
265
266
268
269
270
Using the Principal Form
270
Troubleshoot NNMi Access
271
View the Users who are Signed In to NNMi
271
Audit NNMi User Activity
272
Restore the Administrator Role
273
Restore the System Role
273
Set Up Command Line Access
273
Communicate to Your Team
275
Open the Console
275
Sign Into the NNMi Console
276
Sign Out from the Console
276
Configure Maps
277
Define Default Map Settings
277
Define Node Group Map Settings
279
Node Group Map Settings Form
279
Configure Basic Settings for a Node Group Map
280
Configure the Connectivity to be Displayed for a Node Group Map
284
Configure Background Image Information for a Node Group Map
285
Background Image Sources in Node Group Maps
288
Scale Background Images in Node Group Maps
289
Troubleshoot URLs When Specifying a Background Image
289
Configure a Path View Map
289
Configure Default Settings for Line Graph
293
Configure Menus
294
Page 9 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Configure Menu Items
Configuring Trap Forwarding
294
295
Configure NNMi Security Settings for SNMPv3 Trap Forwarding
295
Configure Trap Forwarding Filters
297
Trap Forwarding Filter Form
297
Filter Form
298
Configure Trap Forwarding Destinations
299
Trap Forwarding Destination Form
300
Destination Filter Form
302
Trap Varbinds Provided by NNMi
Configuring Incidents
Manage Incidents Using Incident Configurations
How NNMi Gathers Incidents
302
304
305
305
The NNMi Causal Engine and Incidents
306
About the Event Pipeline
307
How NNMi Closes Incidents
308
Incident Configurations Provided by NNMi
310
Custom Incident Attributes Provided by NNMi (for Administrators)
310
SNMP Trap Incident Configurations Provided by NNMi
313
Remote NNM 6.x/7.x Event Configurations Provided by NNMi
325
Management Event Configurations Provided by NNMi
327
Incident Pair (Pairwise) Configurations Provided by NNM
336
Manage the Number of Incoming Incidents
Establish Criteria or Relationships for Incoming Incidents
Correlate Duplicate Incidents (Deduplication Configuration)
Deduplication Comparison Parameters Form
Track Incident Frequency (Rate: Time Period and Count)
Rate Comparison Parameters Form
About Pairwise Configurations
338
339
343
343
344
344
344
Incident Pair (Pairwise) Configurations Provided by NNM
345
Prerequisites for Pairwise Configurations
347
Pairwise Configuration Form (Correlate Pairs of Incidents)
348
Pair Item Configuration Form (Identify Incident Pairs)
350
Suppress Incident Configurations
352
Enrich Incident Configurations
352
Page 10 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Dampening Incident Configurations
353
Configure Custom Correlations
353
Configure a Correlation Rule
355
Configure a Parent Incident Filter for a Correlation Rule
357
Configure a Child Incident Filter for a Correlation Rule
364
Configure a Correlation Filter
372
Correlation Rule Example
379
Configure a Causal Rule
382
Configure a Child Incident for a Causal Rule
384
Configure a Child Incident Filter for a Causal Rule
386
Configure a Source Object Filter for a Causal Rule
393
Configure a Source Node Filter for a Causal Rule
400
Causal Rule Example
406
Configure an Action for an Incident
410
Lifecycle Transition Action Form
411
Valid Parameters for Configuring Incident Actions (Management Events)
411
Handling Special Characters in Action Arguments
415
Configure Diagnostics for an Incident (NNM iSPI NET)
417
Diagnostic Selections Form (NNM iSPI NET)
418
Diagnostics (Flows) Provided by NNM iSPI NET
418
Incident Configurations You Might Want to Enable
421
Generate Interface Disabled Incidents
422
Generate Card Disabled Incidents
422
Generate Performance Threshold Incidents (HP Network Node Manager iSPI Performance
for Metrics Software)
422
Manage Incoming SNMP Traps
423
Configure Network Devices to Send SNMP Notifications to NNMi
424
Load SNMP Trap Incident Configurations
425
Load SNMP Trap Incident Configurations from the Command Line
425
Load SNMP Trap Incident Configurations using the Console
426
Control which Incoming Traps Are Visible in Incident Views
427
Handle Unresolved Incoming Traps
428
Analyze Trap Information (NNM iSPI NET)
429
Configure SNMP Trap Incidents
SNMP Trap Configuration Form
Page 11 of 1087
432
433
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Configure Basic Settings for an SNMP Trap Incident
434
Specify the Incident Configuration Name (SNMP Trap Incident)
437
Specify the SNMP Object ID
437
SNMP Object ID Format for SNMP Traps
437
SNMP Object ID Format for SNMPv1 Generic Traps
437
SNMP Object ID Format for a Specific SNMPv1 Trap
438
Display an SNMP Trap or an NNM 6.x/7.x Event as a Root Cause Incident
439
Specify Category and Family Attribute Values for Organizing Your Incidents (SNMP Trap
Incident)
439
Create an Incident Category (SNMP Trap Incident)
440
Create an Incident Family (SNMP Trap Incident)
441
Specify the Incident Severity (SNMP Trap Incident)
442
Specify Your Incident Message Format (SNMP Trap Incident)
442
Valid Parameters for Configuring Incident Messages (SNMP Trap Incident)
442
Include Custom Incident Attributes in Your Message Format (SNMP Trap Incident)
447
Specify a Description for Your Incident Configuration (SNMP Trap Incident)
448
Configure Interface Settings for an SNMP Trap Incident
449
Configure Incident Suppression Settings for an Interface Group (SNMP Trap Incident)
450
Configure Incident Enrichment Settings for an Interface Group (SNMP Trap Incident)
459
Configure Custom Incident Attributes to Enrich an Incident Configuration (Interface
Settings) (SNMP Trap Incidents)
462
Configure a Payload Filter to Enrich an Incident Configuration (Interface Settings)
(SNMP Trap Incidents)
464
Configure Incident Dampening Settings for an Interface Group (SNMP Trap Incident)
469
Configure Incident Actions for an Interface Group (SNMP Trap Incident)
479
Configure a Payload Filter for an Incident Action (Interface Settings) (SNMP Trap
Incidents)
Configure Node Settings for an SNMP Trap Incident
480
485
Configure Incident Suppression Settings for a Node Group (SNMP Trap Incident)
486
Configure Incident Enrichment Settings for a Node Group (SNMP Trap Incident)
496
Configure Custom Incident Attributes to Enrich an Incident Configuration (Node
Settings) (SNMP Trap Incidents)
499
Configure a Payload Filter to Enrich an Incident Configuration (Node Settings) (SNMP
Trap Incidents)
501
Configure Incident Dampening Settings for a Node Group (SNMP Trap Incident)
506
Configure Incident Actions for a Node Group (SNMP Trap Incident)
516
Page 12 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Configure a Payload Filter for an Incident Action (Node Settings) (SNMP Trap
Incidents)
Configure Diagnostics Selections for a Node Group (SNMP Trap Incident) (NNM iSPI
NET)
517
522
Configure Suppression Settings for an SNMP Trap Incident
524
Configure Enrichment Settings for an SNMP Trap Incident
537
Configure Dampening Settings for an SNMP Trap Incident
540
Configure Forward to Global Manager Settings for an SNMP Trap Incident (NNMi
Advanced)
549
Configure Deduplication for an SNMP Trap Incident
558
Deduplication Comparison Parameters Form (SNMP Trap Incident)
Configure Rate (Time Period and Count) for an SNMP Trap Incident
Rate Comparison Parameters Form (SNMP Trap Incident)
Configure Actions for an SNMP Trap Incident
Lifecycle Transition Action Form (SNMP Trap Incidents)
Configure a Payload Filter for an Action (SNMP Trap Incidents)
Valid Parameters for Configuring Incident Actions (SNMP Trap Incident)
Configure Remote NNM 6.x/7.x Events
562
563
565
567
568
570
574
579
Configure Remote NNM 6.x and 7.x Management Stations
579
Remote NNM 6/x/7.x Event Configuration Form
580
Configure Basic Settings for a Remote NNM 6.x/7.x Event Incident
582
Specify the Incident Configuration Name (Remote 6.x/7.x Event)
584
Display an SNMP Trap or an NNM 6.x/7.x Event as a Root Cause Incident
584
Specify Category and Family Attribute Values for Organizing Your Incidents (Remote
NNM 6.x/7x Events)
585
Create an Incident Category (Remote NNM 6.x/7.x Event)
585
Create an Incident Family (Remote NNM 6/x.7.x Event)
586
Specify the Incident Severity (Remote NNM 6.x/7.x Events)
587
Specify Your Incident Message Format (Remote NNM 6.x/7.x Events)
588
Valid Parameters for Configuring Incident Messages (Remote NNM 6.x/7.x Events)
588
Include Custom Incident Attributes in Your Message Format (Remote NNM 6.x/7.x
Events)
593
Specify a Description for Your Incident Configuration (Remote NNM 6.x/7.x Events)
Configure Interface Settings for a Remote NNM 6.x/7.x Event Incident
594
595
Configure Incident Suppression Settings for an Interface Group (Remote NNM 6.x/7.x
Events)
596
Configure Incident Enrichment Settings for an Interface Group (Remote NNM 6.x/7.x
Events)
604
Page 13 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Configure Custom Incident Attributes to Enrich an Incident Configuration (Interface
Settings) (Remote NNM 6.x/7.x Events)
607
Configure a Payload Filter to Enrich an Incident Configuration (Interface Settings)
(Remote NNM 6.x/7.x Events)
609
Configure Incident Dampening Settings for an Interface Group (Remote NNM 6.x/7.x
Events)
614
Configure Incident Actions for an Interface Group (Remote NNM 6.x/7.x Event)
624
Configure a Payload Filter for an Incident Action (Interface Settings) (Remote NNM
6.x/7.x Events)
Configure Node Settings for a Remote NNM 6.x/7.x Event Incident
625
630
Configure Incident Suppression Settings for a Node Group (Remote NNM 6.x/7.x Events)
632
Configure Incident Enrichment Settings for a Node Group (Remote NNM 6.x/7.x Events)
643
Configure Custom Incident Attributes to Enrich an Incident Configuration (Node
Settings) (Remote NNM 6.x/7.x Events)
646
Configure a Payload Filter to Enrich an Incident Configuration (Node Settings)
(Remote NNM 6.x/7.x Events)
648
Configure Incident Dampening Settings for a Node Group (Remote NNM 6.x/7.x Events)
653
Configure Incident Actions for a Node Group (Remote NNM 6.x/7.x Events)
663
Configure a Payload Filter for an Incident Action (Node Settings) (Remote NNM 6.x/7.x
Events)
664
Configure Diagnostics Selections for a Node Group (Remote NNM 6.x/7.x Events)
669
Configure Suppression Settings for a Remote NNM 6.x/7.x Event Incident
671
Configure Enrichment Settings for a Remote NNM 6.x/7.x Event Incident
680
Configure Dampening Settings for a Remote NNM 6.x/7.x Event Incident
683
Configure Forward to Global Managers Settings for a Remote 6.x/7.x Event Incident (NNMi
Advanced)
692
Configure Deduplication for a Remote NNM 6.x/7.x Event Incident
703
Deduplication Comparison Parameters Form (Remote NNM 6.x/7.x Events)
707
Configure Rate (Time Period and Count) for a Remote NNM 6.x/7.x Event Incident
Rate Comparison Parameters Form (Remote NNM 6.x/7.x Events)
708
710
Configure Actions for a Remote NNM 6.x/7.x Event Incident
712
Lifecycle Transition Action Form (Remote NNM 6.x/7.x Events)
713
Configure a Payload Filter for an Action (Remote NNM 6.x/7.x Events)
714
Valid Parameters for Configuring Incident Actions (Remote NNM 6.x/7.x Events)
719
Configure Management Events
724
Management Event Form
724
Page 14 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Configure Basic Settings for a Management Event Incident
726
Specify the Incident Configuration Name (Management Events)
728
Specify Category and Family Attribute Values for Organizing Your Incidents
(Management Events)
729
Create an Incident Category (Management Events)
730
Create an Incident Family (Management Events)
731
Specify the Incident Severity (Management Events)
731
Specify Your Incident Message Format (Management Events)
732
Valid Parameters for Configuring Incident Messages (Management Events)
732
Include Custom Incident Attributes in Your Message Format (Management Events)
737
Specify a Description for Your Incident Configuration (Management Events)
Configure Interface Settings for a Management Event Incident
738
739
Configure Incident Suppression Settings for an Interface Group (Management Events)
740
Configure Incident Enrichment Settings for an Interface Group (Management Events)
748
Configure Custom Incident Attributes to Enrich an Incident Configuration (Interface
Settings) (Management Events)
751
Configure a Payload Filter to Enrich an Incident Configuration (Interface Settings)
(Management Events)
753
Configure Incident Dampening Settings for an Interface Group (Management Events)
758
Configure Incident Actions for an Interface Group (Management Events)
768
Configure a Payload Filter for an Incident Action (Interface Settings) (Management
Events)
Configure Node Settings for a Management Event Incident
769
774
Configure Incident Suppression Settings for a Node Group (Management Events)
775
Configure Incident Enrichment Settings for a Node Group (Management Events)
783
Configure Custom Incident Attributes to Enrich an Incident Configuration (Node
Settings) (Management Events)
786
Configure a Payload Filter to Enrich an Incident Configuration (Node Settings)
(Management Events)
788
Configure Incident Dampening Settings for a Node Group (Management Events)
793
Configure Incident Actions for a Node Group (Management Events)
803
Configure a Payload Filter for an Incident Action (Node Settings) (Management
Events)
Configure Diagnostics Selections for a Node Group (Management Events)
804
809
Configure Suppression Settings for a Management Event Incident
811
Configure Enrichment Settings for a Management Event Incident
822
Configure Dampening Settings for a Management Event Incident
825
Configure Deduplication for a Management Event Incident
837
Page 15 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Deduplication Comparison Parameters Form (Management Events)
Configure Rate (Time Period and Count) for a Management Event Incident
Rate Comparison Parameters Form (Management Events)
Configure Actions for a Management Event Incident
Lifecycle Transition Action Form (Management Events)
Configure a Payload Filter for an Action (Management Events)
Valid Parameters for Configuring Incident Actions (Management Events)
Troubleshoot Incident Configurations
View an Incident Configuration Report
Using Route Analytics Management Software (RAMS) with NNMi Advanced
841
842
844
846
847
848
855
859
860
866
Configure HP Route Analytics Management Software (NNMi Advanced)
866
HP RAMS MPLS WAN Configuration (NNMi Advanced)
867
Enabling the HP NNMi – HP RAMS MPLS WAN Integration
Prerequisites:
867
868
Changing the HP NNMi – HP RAMS MPLS WAN Integration Configuration
868
Disabling the HP NNMi – HP RAMS MPLS WAN Integration
868
HP NNMi – HP RAMS MPLS WAN Integration Configuration Form Reference
868
Extending NNMi Capabilities
870
Control the Actions Menu
870
Create Menu Nesting (in the Actions Menu)
871
Configure Menu Item Basic Details
872
Configure Menu Item Context Basic Details
875
Configure Launch Actions
876
W3C Rules for URLs
880
Attributes per Object Type for Full URLs
881
Capability Attributes in Full URLs
884
Custom Attributes in Full URLs
885
Custom Incident Attributes (CIAs) in Full URLs
886
Database Object Identifiers for Full URLs
887
Path View Attributes for Full URLs
888
Configure SNMP Line Graph Actions
888
MIB Specification Form
891
Configure JavaScript Actions
894
Configure Java Actions
895
Specify Optional Menu Item Enablement Filters
896
Page 16 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Examine Available MIBs and MIB Variables
909
Determine the MIBs Supported for a Node (for Administrators)
909
View the MIBs Loaded on the NNMi Management Server
910
Loaded MIBs View
MIB Form
910
911
Determine the MIB Variables Supported for a Node (for Administrators)
911
Display a MIB File's Contents (Administrators)
913
Upload MIB Files from the Console
913
Load MIBs
914
Load MIBs from the Console
914
Load MIBs from the Command Line
917
Configure MIB Expressions
917
MIB Expressions View
918
MIB Expression Form (Line Graph)
918
Test a MIB Expression (Line Graph)
Use the MIB Expression Editor (Line Graph)
Configure Custom Polling
922
923
927
Enable or Disable Custom Poller
928
Create a Custom Poller Collection
928
Configure Basic Settings for a Custom Poller Collection
930
Specify the MIB Variable Information for a Custom Poller Collection
933
MIB Expressions Form (Custom Poller)
Test a MIB Expression (Custom Poller)
Use the MIB Expression Editor (Custom Poller)
934
936
937
Configure Threshold Information for a Custom Poller Collection
941
Configure Comparison Maps for a Custom Poller Collection
943
Create a Policy
945
Create a Report Group (HP Network Node Manager iSPI Performance for Metrics Software)
948
Create a Report Collection (HP Network Node Manager iSPI Performance for Metrics
Software)
948
Purchase an HP Network Node Manager i Smart Plug-in
950
Integrations with Other HP Products
951
Integration Configuration Form
951
Integrating NNMi Elsewhere with URLs
952
W3C Rules for URLs
Page 17 of 1087
952
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Pass Environment Attributes
953
Launch the Console (showMain)
955
Launch a View (showView)
955
Launch an Incident View
958
Launch the All Incidents View Filtered by Node
960
Launch a Topology Maps Workspace View
962
Launch a Monitoring Workspace View
967
Launch a Troubleshooting Workspace View
970
Launch an Inventory Workspace View
976
Launch a Management Mode Workspace Views
979
Launch a Configuration Workspace View
981
Launch a Form (showForm)
983
Launch a Node Form
983
Launch an Interface Form
986
Launch an IP Address Form
987
Launch a Subnet Form
988
Launch an Incident Form
990
Launch a Node Group Form
991
Launch a Configuration Form
993
Launch Menu Items (runTool)
994
Launch the Actions: Communication Configuration Command
995
Launch the Actions: Configuration Poll Command
996
Launch the Actions: Line Graph (showLineGraph)
997
Launch the Actions: Monitoring Settings Command
998
Launch the Actions: Ping Command
1002
Launch the Actions: Status Details Command (for Node Groups)
1003
Launch the Actions: Status Poll Command
1004
Launch the Actions: Trace Route Command
1005
Actions: Execute a Launch Action
1006
Launch the Tools: MIB Browser (showMibBrowser)
1006
Launch the Tools: NNMi Status Command
1008
Launch the File: Sign-Out Command
1008
Launch the Tools: Sign-In/Out Audit Log Command
1009
Confirm that NNMi Is Running (cmd=isRunning)
Maintaining NNMi
1009
1011
Page 18 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Table of Contents
Check NNMi Health
1011
Track Your NNMi Licenses
1012
Extend a Licensed Capacity
1013
About Environment Variables
1014
Export and Import Configuration Settings
1015
Export/Import Behavior and Dependencies
1015
Export a Snapshot of Your Configuration Settings
1020
Import Configuration Files to Restore Previous Settings
1021
Transfer Configuration Settings to Another NNMi Management Server
1023
Troubleshooting Imports of Configuration Files
1025
Back Up and Restore NNMi
1029
Archive and Delete Incidents
1030
Appendix A: Glossary Terms
1034
Appendix B: Index
1038
Page 19 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Introduction for NNMi Administrators
As an NNMi administrator, you can use the console to configure the items described in the following table.
Configure NNMi
What You Can
Configure
Description
Device Profiles
HP provides well over three thousand pre-configured Device Profiles, one for each
known sysObjectID at the time NNMi released. NNMi uses Device Profiles (which
equate to sysObjectIDs) to control certain types of behavior. Using the Device Profiles
option in the Configuration workspace, you can update Device Profile information.
See "Configure Device Profiles" (on page 134)for more information.
Discovery
Using the Discovery Configuration option in the Configuration workspace, configure
NNMi to discover only those devices that are important to you and your team. See
"Discovering Your Network" (on page 112) for more information.
Filters
Using the Node Groups and Interface Groups options in the Configuration
workspaces, define filters. These filters identify groups of devices. Use the filters to
quickly locate information in views. See "Creating Groups of Nodes or Interfaces" (on
page 179) for more information.
You can also monitor the health of each group, see "Configure Monitoring Behavior"
(on page 214).
Global Network
Management
(NNMi Advanced - Global Network Management feature) Using the Global Network
Management option in the Configuration workspace, you can configure NNMi to
share the workload among multiple NNMi management servers in your network
environment. See "Connecting Multiple NNMi Management Servers (NNMi
Advanced)" (on page 52) .
ICMP and
SNMP
Communication
Protocols
Using the Communication Configuration option in the Configuration workspace,
provide the SNMPv1 or SNMPv2c community strings (read and write) for your network
environment, or provide the SNMPv3 User Names for your network environment.
Configure NNMi settings for timeout, retry, and port usage for ICMP and SNMP traffic.
See "Configuring Communication Protocol" (on page 66) for more information.
Incidents
Using the Incident Configuration option in the Configuration workspace, review the
many predefined incident configurations provided by NNMi . Edit any of the
configurations provided by NNMi or create your own . See "Configuring Incidents" (on
page 304) for more information.
Interface
Groups
Using the Interface Groups option in the Configuration workspace, identify important
devices. Interface Groups are filters for interface and IP address views. Interface
Groups can also control how NNMi monitors network devices. See "Create Interface
Groups" (on page 195) for more information.
Interface Types
Interface Type definitions cover all known industry-standard IANA ifType-MIB variables
at the time of the release of NNMi. Using the IfTypes option in the Configuration
workspace, add a new interface type to the NNMi list of Interface Type definitions. This
option is useful if your team acquires new devices that contain new interface types not
yet provided by NNMi. See "Add New IfTypes (Interface Types) to the List" (on page
206)for more information.
Page 20 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
What You Can
Configure
Description
Management
Stations
(6.x/7.x)
Using the Management Stations (6.x/7.x) option in the Configuration workspace,
configure how events that are received from NNM 6.x or 7.x management stations are
handled by NNMi . See "Configure Remote NNM 6.x and 7.x Management Stations"
(on page 579) for more information.
MIB
Expressions
Using the MIB Expressions option in the Configuration workspace, take a proactive
approach to network management by using SNMP MIB Expressions to specify
additional information that NNMi should poll. See "Configure MIB Expressions" (on
page 917) for more information.
Monitoring
Using the Monitoring Configuration option in the Configuration workspace, define
how and how often important devices are monitored by NNMi . See "Monitoring
Network Health" (on page 213) for more information.
Node Groups
Using the Node Groups option in the Configuration workspace, identify important
devices. You can then filter node, interface, IP address, and incident views by Node
Group. You can also specify Node Groups when configuring monitoring and incidents.
See "Create Node Groups" (on page 179) for more information.
Node Group
Map Settings
Using the User Interface Configuration option in the Configuration workspace,
specify the Node Group map configuration including the Node Group and background
image to be used in a Node Group map. See "Define Node Group Map Settings" (on
page 279) for more information.
Route Analytic
Management
Servers
(RAMS)
(NNMi Advanced) Using the RAMS Servers option in the Configuration workspace,
configure sources of Route Analytics Management Software data for NNMi to use. See
"Using Route Analytics Management Software (RAMS) with NNMi Advanced" (on
page 866).
Sign-In Access
to NNMi
Using the User Interface Configuration option in the Configuration workspace,
provide and control access to NNMi . Configure a name and password for each user.
Assign a role to each user.
Tip: If your environment manages user names and passwords with a directory service,
NNMi can be configured to use Lightweight Directory Access Protocol (LDAP)
instead of the settings in the User Accounts tab of the Configuration → User
Interface Configuration option.
See "Controlling Access to NNMi" (on page 260) for more information.
Status
Using the Status Configuration option in the Configuration workspace, configure how
Node Group Status is calculated. You can choose to assign the Node Group the most
severe status of any Node Group member or configure the percentage thresholds for
one or more Node Group target statuses. See "Configure Node Group Status" (on
page 241)for more information.
Trap
Forwarding
Using the Trap Forward Configuration option in the Configuration workspace,
configure trap forwarding filters and destinations. See "Configuring Trap Forwarding"
(on page 295) for more information.
User Interface
Using the User Interface Configuration option in the Configuration workspace,
configure the following user interface features:
Page 21 of 1087
l
User accounts
l
Default map settings
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
What You Can
Configure
Description
l
Node Group map settings
l
Default Line Graph settings
l
Menus and menu items
NNMi provides a variety of tools to assist you with these configuration tasks. Each of these tools is
described in the following table. You can extend NNMi using HP Network Node Manager i Software Smart
Plug-ins (iSPIs) as described in "Extending NNMi Capabilities" (on page 870).
NNMi Administrator Tools
Tool
Description
Configuration
Workspaces
The console provides a workspace for each kind of item you can configure in NNMi . See
the preceding "Configure NNMi " table for more information.
Lookup
Fields
Provided in forms, fields that include the
icon provide access to a list of all
available attribute values, and in some locations enable you to create attribute values.
See "Lookup Fields" (on page 27) for more information.
Actions
Used to perform automated tasks on a single object or on a group of objects. For
example, you can use the Actions menu to change the Management Mode of one or
more nodes from Managed to Out of Service.
Actions are available from table views, map views, and forms.
See "Actions Provided by NNMi" (on page 30) for more information
NNMi
Processes
and Services
NNMi is built on a group of processes and services. You can list these processes and
services. You can stop and start individual processes and services. See "NNMi
Processes and Services" (on page 44) for more information.
Administrator Tools in the Console
When configuring settings for NNMi, you create configuration object instances. For example, to create a
new URL action, you must create a new URL action instance. As another example, to specify configuration
settings for discovery, you might create object instances that contain ranges of IP addresses that you want
NNMi to use as hints for Spiral Discovery.
The console provides the following tools to assist you with configuration tasks:
l
"Configuration Workspaces" (on page 23)
l
"Lookup Fields" (on page 27)
l
"Create a Configuration Object Instance Using the Form Toolbar" (on page 29)
l
"Delete One or More Objects" (on page 29)
Page 22 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Quick Start Configuration Wizard
Note: Before you use the Quick Start Configuration Wizard, complete the initial configuration checklist. See
Help → Documentation Library → Installation Guide for more information.
The Quick Start Configuration Wizard automatically runs immediately after Network Node Manager (NNMi)
installation completes. Use the Quick Start Configuration Wizard to configure NNMi in a limited (or test)
environment. The Quick Start Configuration Wizard helps you to complete the following initial set up tasks:
l
Provide the read community strings for your SNMPv1 or SNMPv2c environment to enable "Get"
commands
l
Provide the USM settings for your SNMPv3 environment
l
Discover a limited range of network nodes
l
Set up an initial administrator account
You can launch the wizard using the following URL:
Note: If the NNMi Web server uses the https protocol, use https instead of http. (See the"Enabling https
for NNMi" chapter in the HP Network Node Manager i Software Deployment Reference, which is
available at: http://h20230.www2.hp.com/selfsolve/manuals)
http://<serverName>:<portNumber>/quickstart/
<serverName> = the fully-qualified domain name of the NNMi management server (values allowed here
are determined by the Enable URL Redirect setting in User Interface Configuration, see
"Configuring the NNMi User Interface" (on page 257))
<portNumber> = the port that the jboss application server uses for communicating with the NNMi console
Note: HP recommends that you run the Quick Start Configuration Wizard only one time immediately after
NNMi installation.
After using the Quick Start Configuration Wizard to set up a test network, see "Configuration Workspaces"
(on page 23) for information about completing additional NNMi configuration tasks.
Configuration Workspaces
NNMi administrators use the Configuration workspaces to configure the following items related to NNMi.
Note: On tables in configuration forms, if the cursor changes to indicate a hyperlink when you mouse over
a column heading, you are able to sort the column’s data. You cannot change the sort on some of
the tables on the forms in the configuration workspace.
NNMi Configuration Workspaces
Name
Description
Communication
Configuration
Use to configure how NNMi uses ICMP and SNMP in your network environment. See
"Configuring Communication Protocol" (on page 66).
Discovery
Configuration
Use to specify the devices to be discovered. See "Discovering Your Network" (on page
112).
Monitoring
Configuration
Use to enable the NNMi State Poller. See "Monitoring Network Health" (on page 213).
Custom Poller
Use to configure SNMP MIB Expressions that specify additional information NNMi
Page 23 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Name
Description
Configuration
should poll. See "Configure Custom Polling" (on page 927).
Incident
Configuration
Use to specify the information displayed with an incident, including its name, the
message you want to be displayed, the way it should be categorized, its initial status,
and how you want to identify duplicate traps. See "Configuring Incidents" (on page
304).
Trap
Forwarding
Use to forward SNMP trap to other servers in your network environment. See
"Configuring Trap Forwarding" (on page 295).
Status
Configuration
Use to configure Node Group status calculations using either of the following methods:
l
Assign the Node Group the most severe status of any Node Group member. This is
the default.
l
Configure the percentage thresholds for one or more Node Group target statuses.
See "Configure Node Group Status" (on page 241).
User Interface
Configuration
Use to configure many user interface features:
l
The NNMi console time-out interval.
l
The initial view that you want NNMi to display.
l
Specify that NNMi users must provide one of the following in the URL for
accessing NNMi:
l
n
The Fully Qualified Domain Name (FQDN) of the NNMi management server.
n
Any hostname or IP address associated with the NNMi management server
(NNMi automatically redirects these to the FQDN)
Whether NNMi displays unlicensed features that require a special license, such
as NNMi Advanced.
See "Configuring the NNMi User Interface" (on page 257).
Default Map Settings tab - Use to configure the default settings for map views.
These settings can be overridden for a specific map using the Node Group Map
Settings tab. See "Configure Maps" (on page 277).
Default Line Graph Settings tab - Use to configure the SNMP MIB data that you
want to make available to your network operators in a graph format. This graph is
available through the Actions menu and displays in real time. See "Configure Default
Settings for Line Graph" (on page 293).
User Accounts tab - Use to assign NNMi users to NNMi roles. See "Configure SignIn Access" (on page 260).
Note: If NNMi role assignments are stored in your environment's directory service
database, this view is not needed and is not visible. See "Control Access with
a Directory Service" (on page 269).
User Principals tab - This view stores NNMi user names. Principal object instances
are automatically created when you configure access to the NNMi console (using the
User Accounts and Roles view) according to the following scenarios: "Control
Access with NNMi Accounts" (on page 264) and "Control Access Using Both
Page 24 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Name
Description
Directory Service and NNMi" (on page 266).
Note: If NNMi role assignments are stored in your environment's directory service
database, this view is not needed and should remain empty. See "Control
Access with a Directory Service" (on page 269).
Directory Service and NNMi" (on page 266).
Directory Service and NNMi" (on page 266).
Node Group Map Settings tab - Use to specify the Node Group and background
image to be used in a Node Group map. Map settings include the following:
l
Node group name
l
The order in which Node Group maps should appear in the Topology workspace
l
Minimum role for saving edited locations for each node in the map
l
Refresh information
l
Connectivity information
l
Background image URL
l
Background image scale
Menu Items tab - Use to make changes or additions to the items available in the
Actions menu. See "Configure Menu Items" (on page 294).
Global Network
Management
(NNMi Advanced - Global Network Management feature) Use to configure
communication between Global Managers and Regional Managers in your network
environment. See "Connecting Multiple NNMi Management Servers (NNMi
Advanced)" (on page 52).
Node Groups
Use to group your devices for viewing and monitoring purposes. See "Create Node
Groups" (on page 179).
Interface
Groups
Use to group your devices for viewing and monitoring purposes. See "Create Interface
Groups" (on page 195).
IfTypes
Use to determine the list of available interface types. NNMi administrators use these
ifTypes to define Interface Groups. See "Add New IfTypes (Interface Types) to the List"
(on page 206).
Device Profiles
Use to see and edit device profile information. Device profile information includes the
SNMP object ID, model, and vendor. See "Configure Device Profiles" (on page 134).
Loaded MIBs
Use to determine the MIBs loaded on the NNMi management server. See "Examine
Available MIBs and MIB Variables" (on page 909).
MIB
Expressions
Use to determine the MIB Expressions available for Custom Poller or Line Graphs.
See "Create a Custom Poller Collection" (on page 928) and "Configure SNMP Line
Graph Actions" (on page 888).
RAMS Servers
(NNMi Advanced) Use to configure sources of Route Analytics Management Software
data for NNMi to use. See "Using Route Analytics Management Software (RAMS) with
NNMi Advanced" (on page 866).
Page 25 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Name
Description
Management
Stations
(6.x/7.x)
Use to configure NNMi to receive data from NNM 6.x or 7.x management stations in
your network environment. See "Configure Remote NNM 6.x/7.x Events" (on page
579).
Enable or Disable Configurations
Using the Actions menu, you can enable or disable one or more of the following configurations:
Note: When you enable or disable a configuration, NNMi assigns the value Customer as the Author
name. See Author form for important information.
Enable or Disable NNMi Configurations
Configuration
Configuration Workspace Option
SNMP Traps
Incident Configuration
Remote NNM 6.x/7.x Events
Incident Configuration
Management Events
Incident Configuration
Pairwise
Incident Configuration
Menus
User Interface Configuration
Menu Items
User Interface Configuration
To enable an NNMi configuration:
1. Navigate to the table view of the configurations you want to change. For example, select User
Interface Configuration from the Configuration workspace and select the Menus tab.
2. To enable a configuration, click the
to enable.
Open icon in the row representing the configuration you want
3. Select Actions → Enable Configuration.
If you are in the configuration form, NNMi selects Enabled
If you are in the table view, NNMi displays a
selected.
.
check in the Enabled column for each instance
To disable an NNMi configuration:
1. Navigate to the table view of the configurations you want to change. For example, select User
Interface Configuration from the Configuration workspace and select the Menus tab.
2. Do one of the following:
a. To disable a configuration, click the
you want to edit.
Open icon in the row representing the configuration
b. To disable more than one configuration, click the
Show View in New Window icon to open
the table view in a new window. Select each configuration instance that you want to disable.
3. Select Actions → Disable Configuration.
If you are in the configuration form, NNMi removes the check mark from Enabled
.
Page 26 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
If you are in the table view, NNMi removes the
selected.
check mark in the Enabled column for each instance
Lookup Fields
Lookup fields have the following icon:
.
The Lookup field represents an associated object instance. For example, an Incident form has an
associated Source Node attribute. Information about this source node is available in and accessed
through the Lookup field.
Possible Drop-Down Menu Options in Lookup Fields
Option Description
See a subset of information about the selected object. (Use
Quick
View
Open to see all available
information about this object.)
Display a list of valid choices for populating the current attribute field.
Quick
Find
Open
Open the form for the related object instance that is currently selected in the lookup field.
Review all attributes of the related object. Depending on your role, you can edit these attributes.
Create a new object instance to relate to the current object.
New
You can use Lookup fields in a variety of ways:
l
Read-only fields - to provide additional information about the associated object. Click
View or
l
Quick
Open to see the details of this object.
Selection fields - to change the association to another object instance. Click Quick Find to select
from a list of previously configured objects ("Use the Quick Find Window" (on page 28)).
Or type a case-sensitive string into the input box ("Use Autocomplete" (on page 28)).
Page 27 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
l
Read-write fields - create an entirely new object instance for this association. Click
empty form opens for you to fill in, creating a new object instance.
New. An
Use the Quick Find Window
The
Quick Find option is available only in Lookup fields that are modifiable. Use the
Quick Find
option to see the list of available object instances appropriate for populating the current Lookup field.
To list all existing object instances that could be related to the current object:
1. From the lookup field of interest, click the
2. Select
Look up icon:
Quick Find.
NNMi displays a table view of object instances that are available to associate with to the current
object instance.
3. In the Quick Find window, do one of the following:
n
Click the
Make Empty icon to remove an association with this object. The Quick Find window
closes, and the current lookup field is empty.
n
Select This Item icon that precedes the table row containing an object instance. The
Click the
Quick Find window closes, and the object instance you selected populates the current lookup
field.
n
Click the
n
Click the
Quick View icon to display a subset of available object attributes.
Close icon to return to the previous form.
Use Autocomplete
The autocomplete feature is available only in Lookup fields that are modifiable. As you type, NNMi lists the
available object instances for populating the current Lookup field.
To use the autocomplete feature:
1. Start typing the first few letters (case-sensitive) of the name of the object you want to associate with
the current one.
Page 28 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
The Lookup field displays a drop-down list below the input field. This list includes all potential
existing objects with names that match the letters as you enter them.
2. Use the scroll arrows or the mouse to select from the displayed list.
The selected object populates the lookup field and is now associated with the current object.
Create a Configuration Object Instance Using the Form Toolbar
You can save time by generating a new form from within another form. The new form is based on the
object type for the original form and contains only the default values set by NNMi for particular attributes for
that object. Any attributes that have no default value appear blank.
This tool is useful when you want to create multiple object instances that have similar attribute values.
To create a new object instance using the form toolbar:
1. Open the form representing the object of interest.
2. From the form toolbar, click the
Save and New icon.
A new form appears that contains the default attribute values for the object type represented by the
original form.
3. Select the
Save and Close icon to save your changes and return to the view.
Delete One or More Objects
Each row in a table view and each symbol in a map view represents an instance of the object type being
displayed. For example, in a node view, each row of the table represents an instance of a node in your
network.
NNMi administrators can delete object instances. For example, you might need to delete a node that is no
longer being managed.
All objects related to the deleted object are also deleted. For example, if a node object is deleted, all of its
interfaces, network addresses, and its SNMP Agent are deleted. Related connections with either zero or
one end points remaining are deleted. Related subnets and VLANs with zero remaining members are
deleted. The time required for NNMi to finish deleting depends on the number of objects or related objects
being deleted.
To delete an object instance:
1. Select the object of interest:
n
In a table view, select the
n
In a map view, click the map symbol.
n
In a form, proceed to step 2.
2. To delete the object, click the
check box in the row that represents the object.
Delete icon.
The object is deleted from the NNMi database and removed from the current view.
Page 29 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
To delete multiple object instances:
1. Select the objects of interest:
n
n
In a table view, do one of the following:
o Select the
check box in the row that represents each object you want to delete.
o Select the
check box above the check-box column to select all objects in the view.
In a map view, CTRL-Click each map symbol.
2. To delete the objects, click the
Delete icon.
Note: For Node objects, you can use this method to delete up to 20 nodes at one time. You can use
the command line method to delete any number of nodes. See "Delete Nodes" (on page 170)
for more information.
Tip: For all other objects, you can delete any number.
Each object is deleted from the NNMi database and removed from the current view.
Actions Provided by NNMi
Note: (NNMi Advanced - Global Network Management feature) If your NNMi console is a Global Manager
and the selected node is being managed by a Regional Manager (another NNMi management
server in your network environment), some actions are not available.
The following tables describe the actions provided by NNMi:
Actions Provided for Incidents
Actions Provided for Nodes
Actions Provided for Interfaces
Actions Provided for Addresses
Actions Provided for Node Groups
Actions Provided for Interface Groups
Actions Provided for Custom Polled Instances
Actions Provided for Router Redundancy Member, Tracked Object, and Node Component
As shown in the table, the actions available depend on the object selected.
Note: You can also use the Actions menu to access views and possibly NNM 6.x/7.x features. See Access
NNM 6.x and 7.x Features for more information about the available NNM 6.x/7.x actions.
Actions Provided for Incidents
Action
Description
Node Actions
Provides access to all of the actions available for a the Incident's Source Node. See
Actions Provided for Nodes for more information.
Interface
Actions
Only available for incidents with the Source Object attribute value set to Interface.
IP Address
Actions
Only available for incidents with the Source Object attribute value set to IP Address.
Provides access to all of the actions available for an interface. See Actions Provided for
Interfaces for more information.
Page 30 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Provides access to all of the actions available for an IP address. See Actions Provided
for Addresses for more information.
Node Group
Map
Displays the lowest level Node Group map to which the Source Node belongs. For
example, if the node belongs to a Child Node Group, the Child Node Group displays.
See Node Group Maps.
If the Source Node is a member of more than one Node Group at the lowest level, NNMi
prompts you to select the Node Group map you want to display.
If the incident's Source Object is an Island Node Group, NNMi displays the Island Node
Group map. See "Island Node Groups" (on page 209).
Note: Incidents with the Source Object attribute value set to Island Node Group include
Remote site in the incident message. See Island Node Group Map for more
information.
When the selected Source Node is not a member of any Node Group, and you select the
Node Group Map action, NNMi displays an information message.
Path View
Displays a map showing the route between two specified nodes, using the Source Node
as the starting point.
Note: NNMi Advanced. Path View works only with IPv4 addresses. The NNMi Advanced
IPv6 address values are not valid choices for Path View. Any devices in your
network that are configured with IPv6 addresses cannot be displayed on Path
View maps.
Source Node
Displays the Node form of the Source Node object instance.
Source
Object
Displays the form of the source object instance.
Node Group
Members
Island Node Group incidents only. Displays a table of the nodes that are members of the
Island Node Group that is the Source Object for the selected incident. See "Island Node
Groups" (on page 209).
Note: Incidents with the Source Object attribute value set to Island Node Group include
Remote site in the incident message.
Graph
Custom
Poller
Results
Graphs all MIB expressions from each of the Custom Poller Collections associated with
the selected incident's Source Node.
Delete
Deletes the selected Incident object or objects (maximum 20).
To delete more than 20 nodes, see the nnmnodedelete.ovpl Reference Page.
Change
Lifecycle →
In Progress
Changes the lifecycle state to In Progress for the selected incident.
Change
Lifecycle
→Completed
Changes the lifecycle state to Completed for the selected incident.
Change
Lifecycle
Changes the lifecycle state to Closed for the selected incident.
Page 31 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
→Close
Assign →
Assign
Incident
Displays a list of registered users to select from. This user name appears in the
Assigned To column of the incident view.
Assign →
Own Incident
Assigns the incident to the current user. This user name appears in the Assigned To
column of the incident view.
Assign →
Unassign
Incident
Removes the user name from the Assigned To column of the incident view.
Incident
Configuration
Reports →
Displays a report of the configuration settings that define this Incident. See "View an
Incident Configuration Report" (on page 860) for more information.
Open
Incident
Configuration
Displays the selected Incident's configuration form.
Run
Diagnostics
(iSPI NET
only)
(HP Network Node Manager iSPI Network Engineering Toolset Software) When
installed, NNM iSPI NET gathers diagnostic information from the Source Node.
Actions Provided for Nodes
Action
Description
Graphs
Displays a pre-configured graph of real-time data for a selected node.
NNMi provides a set of Line Graph that are configured to display real-time SNMP data.
See Line Graphs Provided by NNMi for more information.
Line Graph graphs can also come from the following sources:
Ping (from
server)
l
Your NNMi administrator might configure additional graphs.
l
NNM iSPI software.
Tests whether a node is reachable using the ping command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Ping issues an ICMP request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Ping accesses that Regional
Manager (NNMi management server) and issues the ICMP request.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Trace Route
(from server)
Traces a route path from the using the traceroute command.
Page 32 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Trace Route issues a request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Trace Route accesses that
Regional Manager (NNMi management server) and issues the request in a
manner appropriate for the operating system in use on the Regional Manager.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Telnet (from
client)
Uses Transmission Control Protocol (TCP) protocol from the computer that launched
your current browser (not the NNMi management server) to open a Telnet (teletype
network) virtual terminal command-line interface from the selected node or Source
Node of the selected object. See Establish Contact with a Node.
Communication
Settings
Displays the communication configuration information for the selected node.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Communication Settings
displays a report, provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Communication Settings
accesses that Regional Manager (NNMi management server) and requests the
report.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Monitoring
Settings
Checks the monitoring configuration settings that were set for a particular node,
interface, or IP address.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Monitoring Settings displays a
report, provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Monitoring Settings accesses
that Regional Manager (NNMi management server) and requests the report.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
List Supported
MIBs
Display a list of the MIBs (Management Information Base) supported by a selected
node. See "Determine the MIBs Supported for a Node (for Administrators)" (on page
909) and Determine a Node's Supported MIBs (MIB Browser) for more information.
Browse MIB
The MIB Browser displays the responses to NNMi's SNMP requests made to a
particular node in your network environment.
Page 33 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Status Poll
Instructs NNMi to gather real-time data for all the information that NNMi uses to
calculate Status for each selected Node (maximum 10). A window for each Node
displays with a report about which information was gathered. The NNMi administrator
determines the list of information gathered by establishing Monitoring configuration
settings. See "Monitoring Network Health" (on page 213) for more information.
Note: To see the resulting Node status, see Verify Current Status of a Device.
Tip: The nnmstatuspoll.ovpl command line tool does the same thing.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Status Poll results are
provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Status Poll requests an
updated copy of the configuration information from the Regional Manager, then the
Global Manager displays the results.
Note: You do not need to sign-in to the Regional Manager.
Configuration
Poll
Runs a real-time configuration check of the selected device to detect any changes
since the last discovery cycle.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Configuration Poll results are
provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Configuration Poll requests
an updated copy of the configuration information from the Regional Manager, then
the Global Manager displays the results.
Note: You do not need to sign-in to the Regional Manager.
Open from
Regional
Manager
Issues a request to the Regional Manager (the NNMi management server that is
responsible for monitoring the selected node) asking to display the Node form of the
selected object.
Note: You must sign into that Regional Manager unless your network environment
provides Single Sign-On (SSO) to that Regional Manager.
Regional
Manager
Console
Issues a request to the Regional Manager (the NNMi management server that is
responsible for monitoring the selected node) asking to display the NNMi console.
Note: You must sign into that Regional Manager unless your network environment
provides Single Sign-On (SSO) to that Regional Manager.
Page 34 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Delete
Deletes the selected object or objects.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Delete removes the Node
object (and all related object data) from the Global Manager's database.
l
Node managed by a Regional Manager = Actions → Delete removes the copy of
the Node object (and all related object data) from the Global Manager's database.
Note: If you need to delete this Node object from the Regional Manager's
database, click Actions → Open from Regional Manager and delete the
Node object. You must sign into that Regional Manager unless your network
environment enables Single Sign-On (SSO) to that Regional Manager
through the Global Manager.
Management
Mode →
Manage
Changes the Management Mode of the selected node to Managed. Leaves the Direct
Management Mode of any contained interfaces and addresses unchanged.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Manage modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Management
Mode →
Manage (Reset
All)
Changes the Management Mode of the selected node to Managed. Sets the Direct
Management Mode of all contained interfaces and addresses to Inherited.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Manage (Reset All) modifies the Node object plus all associated interface objects
and address objects in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Page 35 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Management
Mode →
Unmanage
Changes the Management Mode of the node to Not Managed. Leaves the Direct
Management Mode of any contained interfaces and addresses unchanged.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Unmanage modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Management
Mode → Out of
Service
Changes the Management Mode of the selected node to Out of Service. Leaves the
Direct Management Mode of any contained interfaces or addresses unchanged.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode → Out of
Service modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Run
Diagnostics
(iSPI NET only)
(HP Network Node Manager iSPI Network Engineering Toolset Software) When
installed, NNM iSPI NET gathers diagnostic information on the current node.
Show Attached
End Nodes
Displays information about the end nodes that NNMi determines are attached to the
specified switch.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager: The results are based on the current information in the
NNMi database of the Global Manager (which contains copies of Node objects from all
Regional Managers).
Actions Provided for Interfaces
Action
Description
Graphs
Displays a pre-configured graph of real-time data for a selected interface.
NNMi provides a set of Line Graphs that are configured to display real-time SNMP
data. See Line Graphs Provided by NNMi for more information.
Line Graphs can also come from the following sources:
l
Your NNMi administrator might configure additional graphs.
Page 36 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
l
Monitoring
Settings
NNMi SPI software.
Checks the monitoring configuration settings that were set for a particular node,
interface, or address.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Communication Settings
displays a report, provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Communication Settings
accesses that Regional Manager (NNMi management server) and requests the
report.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Communication
Settings
Displays the communication configuration information for the Source node.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Communication Settings
displays a report, provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Communication Settings
accesses that Regional Manager (NNMi management server) and requests the
report.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Management
Mode →
Manage
Changes the Direct Management Mode of the interface to Inherited. Leaves the Direct
Management Mode of any associated addresses unchanged.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Manage modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Page 37 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Management
Mode
→Manage
(Reset All)
Changes the Management Mode of the interface to Inherited. Changes the Direct
Management Mode of any associated addresses to Inherited.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Manage (Reset All) modifies the Node object plus all associated interface objects
and address objects in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Management
Mode →
Unmanage
Changes the Management Mode of the interface to Not Managed. Leaves the Direct
Management Mode of any associated addresses unchanged.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Unmanage modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Management
Mode → Out of
Service
Changes the Management Mode of the interface to Out of Service.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode → Out of
Service modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Page 38 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Actions Provided for Addresses
Action
Description
Ping (from
server)
Tests whether a node is reachable using the ping command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Ping issues an ICMP request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Ping accesses that Regional
Manager (NNMi management server) and issues the ICMP request.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Trace Route
(from sever)
Traces a route path using the traceroute command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Trace Route issues a request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Trace Route accesses that
Regional Manager (NNMi management server) and issues the request in a
manner appropriate for the operating system in use on the Regional Manager.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Telnet (from
client)
Uses Transmission Control Protocol (TCP) protocol from the computer that launched
your current browser (not the NNMi management server) to open a Telnet (teletype
network) virtual terminal command-line interface from the selected node or Source
Node of the selected object. See Establish Contact with a Node.
Communication
Settings
Displays the communication configuration information for the Source node.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Communication Settings
displays a report, provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Communication Settings
accesses that Regional Manager (NNMi management server) and requests the
report.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Monitoring
Settings
Checks the monitoring configuration settings that were set for a particular node,
interface, or address.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Page 39 of 1087
Node managed by the Global Manager = Actions → Monitoring Settings displays a
report, provided by the Global Manager (NNMi management server).
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Ping (from
server)
Tests whether a node is reachable using the ping command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Ping issues an ICMP request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Ping accesses that Regional
Manager (NNMi management server) and issues the ICMP request.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Trace Route
(from sever)
Traces a route path using the traceroute command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Trace Route issues a request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Trace Route accesses that
Regional Manager (NNMi management server) and issues the request in a
manner appropriate for the operating system in use on the Regional Manager.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Telnet (from
client)
Uses Transmission Control Protocol (TCP) protocol from the computer that launched
your current browser (not the NNMi management server) to open a Telnet (teletype
network) virtual terminal command-line interface from the selected node or Source
Node of the selected object. See Establish Contact with a Node.
l
Node managed by a Regional Manager = Actions → Monitoring Settings accesses
that Regional Manager (NNMi management server) and requests the report.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Page 40 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Ping (from
server)
Tests whether a node is reachable using the ping command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Ping issues an ICMP request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Ping accesses that Regional
Manager (NNMi management server) and issues the ICMP request.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Trace Route
(from sever)
Traces a route path using the traceroute command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Trace Route issues a request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Trace Route accesses that
Regional Manager (NNMi management server) and issues the request in a
manner appropriate for the operating system in use on the Regional Manager.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Telnet (from
client)
Uses Transmission Control Protocol (TCP) protocol from the computer that launched
your current browser (not the NNMi management server) to open a Telnet (teletype
network) virtual terminal command-line interface from the selected node or Source
Node of the selected object. See Establish Contact with a Node.
Configuration
Poll
Runs a real-time configuration check of the selected device to detect any changes
since the last discovery cycle.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Configuration Poll results are
provided by the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Configuration Poll requests
an updated copy of the configuration information from the Regional Manager, then
the Global Manager displays the results.
Note: You do not need to sign-in to the Regional Manager.
Management
Mode →
Manage
Page 41 of 1087
Changes the Direct Management Mode of the address to Inherited.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Manage modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Ping (from
server)
Tests whether a node is reachable using the ping command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Ping issues an ICMP request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Ping accesses that Regional
Manager (NNMi management server) and issues the ICMP request.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Trace Route
(from sever)
Traces a route path using the traceroute command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Trace Route issues a request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Trace Route accesses that
Regional Manager (NNMi management server) and issues the request in a
manner appropriate for the operating system in use on the Regional Manager.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Telnet (from
client)
Uses Transmission Control Protocol (TCP) protocol from the computer that launched
your current browser (not the NNMi management server) to open a Telnet (teletype
network) virtual terminal command-line interface from the selected node or Source
Node of the selected object. See Establish Contact with a Node.
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Management
Mode →
Unmanage
Changes the management mode of the address to Not Managed.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode →
Unmanage modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Page 42 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Ping (from
server)
Tests whether a node is reachable using the ping command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Ping issues an ICMP request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Ping accesses that Regional
Manager (NNMi management server) and issues the ICMP request.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Trace Route
(from sever)
Traces a route path using the traceroute command.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Trace Route issues a request
from the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Trace Route accesses that
Regional Manager (NNMi management server) and issues the request in a
manner appropriate for the operating system in use on the Regional Manager.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Telnet (from
client)
Uses Transmission Control Protocol (TCP) protocol from the computer that launched
your current browser (not the NNMi management server) to open a Telnet (teletype
network) virtual terminal command-line interface from the selected node or Source
Node of the selected object. See Establish Contact with a Node.
Management
Mode → Out of
Service
Changes the management mode of the address to Out of Service.
(NNMi Advanced) If the Global Network Management feature is enabled and you are
signed into a Global Manager:
l
Node managed by the Global Manager = Actions → Management Mode → Out of
Service modifies the Node object in the Global Manager's database.
l
Node managed by a Regional Manager = Use Actions → Open from Regional
Manager to set Management Mode on the Regional Manager that is responsible
for this Node.
Note: You must sign into that Regional Manager unless your network environment
enables Single Sign-On (SSO) to that Regional Manager through the Global
Manager.
Actions Provided for Node Groups
Action
Description
Node Group
Map
Displays a current map of all nodes that belong to the selected Node Group.
Page 43 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Action
Description
Show Members
Displays a list of all nodes that belong to the selected Node Group.
Show All
Incidents
Checks for any Incidents associated with the selected Node Group.
Show All Open
Incidents
Checks for any open Incidents associated with the selected Node Group.
Status Details
Displays a report about the status of all members of the selected Node Group. See
Check Status Details for a Node Group.
Actions Provided for Interface Groups
Action
Description
Show Members
Displays a list of all nodes that belong to the selected Node Group.
Actions Provided for Custom Polled Instances
Action
Description
Graph
Polled
Instance
Graphs the line representing the Custom Poll results for the selected Custom Polled
Instance. See Display an Line Graph for a Custom Polled Instance.
Actions Provided for Router Redundancy Member, Tracked Object, and Node Component
Action
Description
Monitoring
Settings
Checks the monitoring configuration settings that were set for the Router Redundancy
Member, Tracked Object, or Node Component. See Verify Monitoring Configuration
Settings and View the Monitoring Configuration Details.
NNMi Processes and Services
NNMi is built on a group of processes and services. For information about each process or service, see the
following:
l
"About Each NNMi Process" (on page 45)
l
"About Each NNMi Service" (on page 46)
To verify that everything is running properly, you can use the ovstatus command:
l
"Verify that NNMi Processes Are Running" (on page 45)
Page 44 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
About Each NNMi Process
HP Network Node Manager Processes
Process
Name
Description
OVsPMD
The control process that manages all the other NNMi processes.
pmd
Event Post Master daemon. This process routes events from the producers to the
consumers. Producers of events are NNM 6.x/7.x management stations and processes.
Consumers of events are the event pipeline and third party applications.
ovjboss
The process that controls the jboss application server that contains all of the NNMi Services
(see "About Each NNMi Service" (on page 46) for more information).
nnmaction
The process that controls the Action Server. The NNMi Action Server runs any actions
configured for incidents. See "Configure an Action for an Incident" (on page 410) for more
information about incident actions. See also the nnmaction Reference Page for more
information
nmsdbmgr
NMS Database Manager. Controls the NNMi embedded database, including periodic
database connectivity testing.
nmsdbmgr
NMS Database Manager. Controls the NNMi embedded database, including periodic
database connectivity testing.
Verify that NNMi Processes Are Running
After you install Network Node Manager, a group of processes run on the NNMi management server.
To verify that all NNMi processes are running, do one of the following:
1. Select Tools → NNMi Status to display a report.
2. At the command line, type: ovstatus –c
See the ovstatus Reference Page for more information.
Review the list of processes to ensure that all are running. For more information about each process, see
"About Each NNMi Process" (on page 45).
Stop or Start an NNMi Process
You can stop and start NNMi processes from the command line. See the ovstop and ovstart Reference
Pages for more information.
Caution: If your NNMi management server participates in a high availability (HA) environment, under
certain circumstances, you should not use ovstop or ovstart. See the HP Network Node
Manager i Software Deployment Reference before using either of these commands.
To stop or start an NNMi process:
At the command line, type the appropriate command (see "About Each NNMi Process" (on page 45)):
ovstop <process name>
ovstart <process name>
Page 45 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Note: If you use ovstop and ovstart without providing a process name, NNMi stops and starts all NNMi
processes.
To generate a list of process names, see "Verify that NNMi Processes Are Running" (on page 45).
About Each NNMi Service
NNMi Services run inside the ovjboss process. The ovjboss process controls the jboss application server
that contains all of the NNMi services.
HP Network Node Manager Services
ovjboss Service Name
Description
CommunicationParametersStatusService
Tracks internal statistics for measuring SNMP and ICMP
configuration performance.
IslandSpotterService
Automatically discovers any Island Node Groups using Layer
2 connectivity information in the topology.
An Island Node Group is a group of fully-connected nodes
discovered by NNMi, and NNMi determines this group is not
connected to the rest of the topology.
ManagedNodeLicenseManager
Responsible for ensuring that the number of managed nodes
does not exceed the NNMi licensed capacity limit.
ModelChangeNotificationAdapter
Emits notifications when certain model changes happen
(discovery seeds, global settings, Spiral Discovery
configuration, management node).
MonitoringSettingsService
Calculates how to monitor each device based on the
Monitoring Configuration settings.
NamedPoll
NMS Named Poll Service. Used to trigger immediate state
polls for monitored objects. Used by the Causal Engine
during neighbor analysis and interface up/down
investigations.
NmsApa
NMS Active Problem Analyzer (APA) service determines the
root cause of network problems and reports the root cause to
the NMS Event Service. The Causal Engine is a key
component of the NNMi APA service.
NmsDisco
NMS Discovery Service. Adds new devices to the database
and keeps the configuration of the managed devices up to
date in the database by periodically rechecking the
configuration of the devices.
State Poller uses the Discovery service results to determine
what to monitor.
The Causal Engine depends on the Discovery service to
monitor node configurations. The Causal Engine uses the
configuration information when calculating status and root
cause.
NNMi uses the information provided by the Discovery service
to maintain current device configuration information.
Page 46 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
ovjboss Service Name
Description
NmsEvents
NMS Events Service. Populates and manages the
information displayed in the incident table. The information
displayed comes from the other NNMi services that are
running on your system. The incidents are filtered so you see
only the most important information about your network.
NmsEventsConfiguration
Handles incident configuration changes.
NmsModel
NMS Topology Model Service. Enables communication
between NNMi services and the NNMi database.
SpmdjbossStart
The SpmdjbossStart service interacts with the OVsPMD
process during startup (ovstart), shutdown (ovstop), and
reporting on the status of the ovjboss services (ovstatus –v
ovjboss).
Caution: If your NNMi management server participates in a
high availability (HA) environment, under certain
circumstances, you should not use ovstop or
ovstart. See the HP Network Node Manager i
Software Deployment Reference before using either
of these commands.
StagedIcmp
Used by the State Poller to ping IP addresses using the
Internet Control Message Protocol (ICMP). Also used by
auto-discovery if Ping Sweep is enabled.
StagedSnmp
Used by the State Poller and Discovery to perform Simple
Network Management Protocol (SNMP) read-only queries.
StatePoller
NMS State Poller Service. State Poller collects
measurements that assess the current state of discovered
devices. This information is provided for the Causal Engine to
use when calculating device health.
HP Network Node Manager iSPI Network Engineering Toolset Software Services (NNM iSPI
NET)
ovjboss Service
Name
RbaManager
Description
(HP Network Node Manager iSPI Network Engineering Toolset Software) Used
for diagnostics.
Verify that NNMi Services are Running
After you install Network Node Manager, a group of services run on the NNMi management server. For
information about each service, see "About Each NNMi Service" (on page 46).
To verify that all NNMi services are running, do one of the following:
l
Select Tools → NNMi Status to display a report.
l
At the command line, type:
Page 47 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
ovstatus –v ovjboss
See the ovstatus Reference Page for more information.
Review the list of services to ensure that all are running.
"Service is started" means this service is working properly.
"Service is stopped" means this service/process is not running.
If you see any of the messages in this list, investigate the log files and look for the keyword Exception
(within the log file for the parent ovjboss process and the log file for the specific service, possible services
are listed in the table below ):
"Service is in created state"
"Service is in failed state"
"Service is in registered state"
"Service is in destroyed state"
"Service is in started state"
"Service is in starting state"
"Service is in stopped state"
"Service is in stopping state"
"Service is in unregistered state"
Log files are found in the following location. If your NNMi management server participates in a high availability (HA) environment, click here for more information:
1. Before opening the log file, first identify the HA_MOUNT_POINT for your NNMi environment.
2. At the command line, type:
Windows:
%NnmInstallDir%/misc/nnm/ha/nnmhaclusterinfo.ovpl NNM –config –get HA_MOUNT_
POINT
UNIX:
opt/OV/misc/nnm/ha/nnmhaclusterinfo.ovpl NNM –config –get HA_MOUNT_POINT
3. At the command line, type the following (/DataDir/ is the literal path):
<HA_MOUNT_POINT>/DataDir/log/nnm
l
Windows:
%NnmDataDir%\log\nnm\<name>.%g.%u.log
l
UNIX:
/var/opt/OV/log/nnm/<name>.%g.%u.log
%g = Zero (0) for active log files. Any other number means an archived log file from previous restarts or
from reaching log file size limits. See logging.properties for information about controlling the number of
archives saved for each log file or for controlling the size of each log file.
%u = Zero (0) unless the parent ovjboss process failed during a logging session. While NNMi is logging
information, it creates a file named nnm.0.0.log.lck (the lock file). NNMi deletes the lock file when it
finishes logging. If a nnm.0.0.log.lck file already exists, NNMi creates nnm.0.1.log.lck file and
writes to the nnm.0.1.log file.
The parent ovjboss process generates the following log files:
l
ovjboss.log and ovjboss.log.old
l
jbossServer.log and jbossServer.<date>.log
Page 48 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction for NNMi Administrators
Note: Each restart creates a new ovjboss.log and overwrites the ovjboss.log.old. Each day a new
jbossServer.log file is created, and the previous day's file is renamed by inserting a date stamp
jbossServer.<date>.log
Stop or Start NNMi Services
You can stop or start all NNMi services at the same time. You cannot start and stop individual services.
See the ovstop and ovstart Reference Page for more information.
Caution: If your NNMi management server participates in a high availability (HA) environment, under
certain circumstances, you should not use ovstop or ovstart. See the HP Network Node
Manager i Software Deployment Reference before using either of these commands.
To stop or start the NNMi services:
At the command line, type the command:
ovstop ovjboss
ovstart ovjboss
Page 49 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Introduction to IPv6 in NNMi-Advanced
Introduction to IPv6 in NNMi-Advanced
IPv6 upgrades IPv4 features and allows for vastly more address space, built-in security, and enhanced
support for streaming media and peer-to-peer applications.
When your network environment includes both IPv4 and IPv6, your NNMi administrator can configure
NNMi to automatically detect and monitor both types of addresses, whether devices are IPv4-only, IPv6only, or dual-stack (both).
Note: The NNMi administrator must enable IPv6 with a setting in the nms-jboss.properties file. See the
HP Network Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals
If enabled for IPv6, NNMi-Advanced allows IPv6 addresses and address ranges in the following:
l
SNMP communication (address ranges and specific addresses), see "Configuring Communication
Protocol" (on page 66). The NNMi administrator specifies whether NNMi prefers IPv4 or IPv6
addresses when selecting the Management Address (settings in the nms-jboss.properties file).
l
Discovering address information about devices in your network (Include or exclude address ranges
and specific addresses. Use IPv6 for discovery seeds.). See "Discovering Your Network" (on page 112)
and "IPv6 Addresses Prerequisite (NNMi Advanced)" (on page 125).
Note: IPv6 addresses are automatically excluded from Ping Sweep if you configure NNMi to use Ping
Sweep as a starting point for discovery. NNMi detects the IPv6 addresses later in the discovery
process. IPv6 address cannot be used when manually configuring representations of subnet
connections that NNMi cannot otherwise detect (the optional Subnet Connection Rules aspect
of Discovery).
l
Monitoring a subset of the discovered devices using Node Group and Interface Group filters (through
address filters and specific address lists), see "Monitoring Network Health" (on page 213).
l
NNMi uses ICMPv6 communication for IPv6 Address fault monitoring.
l
Configure NNMi fault monitoring to generate incidents about a subset of the discovered devices using
Node Group and Interface Group filters (address filters and specific addresses), see "Configuring
Incidents" (on page 304).
NNMi documents the associations between IPv6 Addresses, Subnets, Interfaces, and Nodes and presents
consolidated IPv4 and IPv6 information. See Accessing Device Details.
NNMi provides Layer 2 Neighbor Views, Layer 3 Neighbor Views, and Topology Maps of IPv4 and IPv6
devices combined.
Note: Path View does not include IPv6 addresses.
The NNMi console's Actions → Ping (from server) and Actions → Trace Route (from server) menu
items work with both IPv4 and IPv6. See Test Node Access (Ping) and Find the Route (traceroute).
Page 50 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Use NNMi Help Anywhere, Anytime
Use NNMi Help Anywhere, Anytime
The NNMi Help system can run independently from the console. Simply unzip the files into any convenient
location.
To locate the NNMi Help files, on the NNMi management server, navigate to the location appropriate for
the NNMi management server's operating system (see table).
Location of the NNMi Help System
Operating System
NNMi Help System Files
Windows
%NnmInstallDir%\nonOV\jboss\nms\server\nms\deploy\nnmDocs_en.war
UNIX
/opt/OV/nonOV/jboss/nms/server/nms/deploy/nnmDocs_en.war
To access Help independently from the console:
1. Copy the web archive file nnmDocs_en.war to any convenient location.
2. At the command prompt, navigate to the directory where you placed the nnmDocs_en.war file. To
extract the help directory structure and files, type:
jar xvf nnmDocs_en.war
Tip: You can also use WinZip on Windows to decompress the nnmDocs_en.war file.
3. Navigate to and open the /htmlHelp/nmHelp/nmHelp.html file.
4. The NNMi Help system runs as usual in the default browser window.
To Access a PDF version of the NNMi online help:
Go to: http://h20230.www2.hp.com/selfsolve/manuals
This site requires that you register for an HP Passport ID. To obtain an HP Passport ID, go to:
http://h20229.www2.hp.com/passport-registration.html
Page 51 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Connecting Multiple NNMi Management Servers (NNMi Advanced)
The Global Network Management feature enables you to configure NNMi to share the workload among
multiple NNMi management servers in your network environment. For more information about the Global
Network Management feature, click here:
(NNMi Advanced) There are many benefits to using the NNMi Global Network Management feature:
l
Provides safe and secure communication among multiple NNMi management servers.
l
Provides a central big-picture view of your corporate-wide network on the Global Manager for 24hour/7-days-per-week coverage.
l
Easy to set up:
n
Each Regional Manager administrator specifies all Node object data or a specific Node Group for
participation at the Global Manager level.
n
Each Global Manager administrator specifies which Regional Managers are allowed to contribute
information.
l
Automatically combines topology from multiple NNMi management servers on the Global Manager, but
keeps management responsibilities separate. (No duplication, the responsible NNMi Management
server is clearly identified per Node.)
l
Generates and manages Incidents independently on each server (generated within the context of
topology available on each server).
l
Regional Manager administrators can configure specific SNMP traps or NNM 6.x/7.x Events to be
forwarded from Regional Managers to Global Managers.
Review the Global Network Management deployment choices in the HP Network Node Manager i
Software Deployment Reference (available at: http://h20230.www2.hp.com/selfsolve/manuals).
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, the
UNIX (HP-UX / Linux / Solaris) tool Network Time Protocol Daemon (NTPD) or one of the available
Windows operating system tools.Review the Global Network Management deployment choices in the HP
Page 52 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Network Node Manager i Software Deployment Reference (available at:
http://h20230.www2.hp.com/selfsolve/manuals).
To configure Global Network Management, do the following:
1. Navigate to the Global Network Management form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Global Network Management.
2. Do one of the following:
n
Global Manager. If you are the NNMi administrator for the Global Manager, decide which
Regional Managers are allowed to forward network information to that Global Manager (NNMi
management server). See "Global Manager: Connect to a Regional Manager" (on page 55).
Each Regional Manager retains management responsibilities for the forwarded nodes. The
Global Manager might or might not directly manage a set of network devices.
n
Regional Manager. If you are the NNMi administrator for the Regional Manager, you control the
following aspects of communication with the Global Manager:
o Forward information about all Node object data or only data about Nodes belonging to one
Node Group. See "Regional Manager: Create a Forwarding Filter (Limit the available Node
information)" (on page 53).
Note: Incidents associated with the specified Nodes are not forwarded to the Global Manager.
Each server maintains an independent group of incidents.
o Forward specific SNMP traps and NNM 6.x/7.x Events to the Global Manager. See "Configure
Forward to Global Manager Settings for an SNMP Trap Incident (NNMi Advanced)" (on page
549) and "Configure Forward to Global Managers Settings for a Remote 6.x/7.x Event Incident
(NNMi Advanced)" (on page 692).
3. Click
Save and Close to apply your changes.
After Global Network Management is set up in your network environment:
l
To troubleshoot any issued with Global Network Management, see "Troubleshoot Global Network
Management" (on page 61).
l
To determine which Nodes are monitored by each NNMi management server, see View the NNMi
Management Servers' Domain List.
l
To determine which Incidents were forwarded to the Global Manager, see Monitor Incidents in a Global
Network Management Environment (NNMi Advanced).
Regional Manager: Create a Forwarding Filter (Limit the available Node
information)
(NNMi Advanced - Global Network Management feature) As administrator of the Regional Manager, you
can specify which Node object data Global Managers can access:
To provide all Node object data to Global Managers in your environment, click here.
Do nothing. NNMi automatically forwards all Node object data unless a Forwarding Filter is defined.
To limit available Node object data by creating a Forwarding Filter, click here.
(NNMi Advanced - Global Network Management feature) The Global Manager and the Regional Manager
Page 53 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
maintain separate sets of data. Conclusions about each Node are derived from the available data and can
sometimes be different. Regional Managers forward the results of each Auto-Discovery cycle to the Global
Manager. The Regional Manager can have a Node Group filter configured to limit the amount of data that
is forwarded to the Global Manager. Filters are usually unnecessary for Global Network Management. Do
not filter out nodes that are important for connectivity in your network environment to ensure NNMi has the
data needed for accurate root cause analysis.
1. Navigate to the Global Network Management form:
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Global Network Management form.
2. Select the Forwarding Filter tab.
3. Click the Node Group
Lookup icon and select one of the options from the drop-down menu:
n
Quick View to display summary information for the currently configured (selected) Node Group
name.
n
Quick Find to view and select from the list of all existing Node Groups (for more information
see "Use the Quick Find Window" (on page 28)).
n
Open to display the details of the currently configured (selected) Node Group (see Node
Group form for more information).
n
New to create a new Node Group (see "Create Node Groups" (on page 179) for more
information).
4. Click
Save and Close.
5. Global Managers in your network environment can now access only information about the Nodes in
the specified Node Group. If any Global Managers have previously gathered a wider range of Node
object data, that extra data is automatically removed from the Global Managers database.
To verify that your Forwarding Filter is working as expected, wait until the next NNMi rediscovery
cycle finishes on your NNMi management server and then log onto the Global Manager. Follow the
directions in View the NNMi Management Servers' Domain List. You should see only the members of
the Node Group specified as your Forwarding Filter.
Incidents associated with the specified Nodes are not forwarded to the Global Manager. Each server
maintains an independent group of incidents.
Regional Manager administrators can make exceptions to this for SNMP traps and NNM 6.x/7.x events.
The administrator must specifically configure forwarding to the Global Managers:
l
"Configure Forward to Global Manager Settings for an SNMP Trap Incident (NNMi Advanced)" (on
page 549)
l
"Configure Forward to Global Managers Settings for a Remote 6.x/7.x Event Incident (NNMi
Advanced)" (on page 692)
To identify these specifically forwarded SNMP traps and NNM 6.x/7.x events on the Global Manager, see
Monitor Incidents in a Global Network Management Environment (NNMi Advanced).
Page 54 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Global Manager: Connect to a Regional Manager
(NNMi Advanced - Global Network Management feature) As administrator, you can set up this NNMi
management server as a Global Manager that displays information from other NNMi management servers
(Regional Managers).
Tip: If the group of nodes being managed by a Regional Manager overlaps with the nodes already being
managed by the Global Manager, the duplicate information from the Regional Manager is not imported
into the Global Manager's database. If two Regional Managers are managing the same node, only the
first instance to be forwarded is added to the Global Manager's database.
To enable communication from this NNMi management server to another in your network:
1. Prerequisite:
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, the UNIX (HP-UX / Linux / Solaris) tool Network Time Protocol Daemon (NTPD) or one of
the available Windows operating system tools.
Review the Global Network Management deployment choices in the HP Network Node Manager i
Software Deployment Reference (available at:
http://h20230.www2.hp.com/selfsolve/manuals).
2. Complete the required steps described in the HP Network Node Manager i Software Deployment
Reference (available at: http://h20230.www2.hp.com/selfsolve/manuals), then navigate to
the Global Network Management form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Global Network Management form.
3. Select the Regional Manager Connections Tab.
4. Do one of the following:
n
To create a new configuration, click the
n
To edit a configuration, click the
to edit.
n
DO NOT delete a configuration (the
Delete icon). See "Disconnect Communication with a
Regional Manager" (on page 59) for more information.
New icon.
Open icon in the row representing the configuration you want
5. In the Regional Manager form, provide the basic configuration settings (see basic settings table).
6. From the Connection tab, navigate to the Regional Manager Connection form (see "Global Manager:
Configure the Regional Manager Connection" (on page 56) for more information). Do one of the
following:
n
To create a new connection, click the
n
To edit a connection, select a row, click the
n
To delete a connection configuration, select a row and click the
New icon.
Open icon.
Delete icon.
7. Click
Save and Close to return to the Regional Manager form.
8. Click
Save and Close to return to the Global Network Management form.
Page 55 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
9. Click
Save and Close. NNMi establishes communication with the specified Regional Manager.
That NNMi management server now forwards information about discovery and monitoring results to
this NNMi management server.
Tip: To verify that the connection is working, see "Determine the State of the Connection to a Regional
Manager" (on page 62).
Basic Settings for this Regional Manager (NNMi Management Server)
Attribute
Description
Name
Type a meaningful name for this configuration record about the Regional NNMi
management server. For example:
l
The name your team uses to refer to the Regional NNMi management server.
l
The company site being managed by the Regional Manager.
l
The geographic area (Japan or Germany) being managed by the Regional Manager.
The text you type appears in the Node view and NNMi Management Server view. This text
string also appears in the Nodes by Management Server view's drop-down filter.
Alpha-numeric and special characters (~ ! @ # $ % ^ &amp; * ( ) _+) are allowed. No
spaces are allowed.
Note: Communicate this Name attribute value to your team so they understand the
relationship between this name and the NNMi management server's DNS name
(used to log onto that NNMi management server).
Description
Optional. Provide any description that would be useful for communication purposes within
your team.
Type a maximum of 255 characters. Alpha-numeric, spaces, and special characters (~ ! @
# $ % ^ &amp; * ( ) _+) are allowed.
Global Manager: Configure the Regional Manager Connection
(NNMi Advanced - Global Network Management feature) As administrator, you configure how this NNMi
management server communicates with another NNMi management server in your network environment
(the Regional Manager).
Tip: If the group of nodes being managed by a Regional Manager overlaps with the nodes already being
managed by the Global Manager, the duplicate information from the Regional Manager is not imported
into the Global Manager's database. If two Regional Managers are managing the same node, only the
first instance to be forwarded is added to the Global Manager's database.
To configure the communication connection to another NNMi management server:
1. Prerequisite:
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, the UNIX (HP-UX / Linux / Solaris) tool Network Time Protocol Daemon (NTPD) or one of
the available Windows operating system tools.
Page 56 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Review the Global Network Management deployment choices in the HP Network Node Manager i
Software Deployment Reference (available at:
http://h20230.www2.hp.com/selfsolve/manuals).
2. Navigate to the Regional Manager Connection form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Global Network Management form
c. Select the Regional Manager Connections tab.
d. Do one of the following:
o To create a new configuration, click the
o To edit a configuration, click the
New icon.
Open icon in the row representing the configuration
you want to edit.
o DO NOT delete a configuration (the
Delete icon). See "Disconnect Communication
with a Regional Manager" (on page 59) for more information.
e. In the Regional Manager form, navigate to the Connections tab. Do one of the following:
o To create a new connection, click the
New icon.
o To edit a connection, select a row, click the
Open icon.
o To delete a connection configuration, select a row and click the
Delete icon.
3. Provide the connection configuration settings (see connection configuration settings table).
Note: If the Regional Manager participates in a high-availability (HA) environment, enter
configuration settings for each server in the high-availability group (application fail-over).
4. Click
Save and Close to return to the Regional Manager form.
5. Click
Save and Close to return to the Global Network Management form.
6. Click
Save and Close. NNMi establishes communication with the Regional NNMi management
server. The Regional Manager forwards information about discovery and monitoring results.
Tip: To verify that the connection is working, see "Determine the State of the Connection to a Regional
Manager" (on page 62).
Connection Configuration Settings for a Regional NNMi Management Server
Attribute
Description
Hostname
The official fully-qualified-domain-name of the Regional Manager (the NNMi management
server). To verify the correct value, do one of the following:
l
Log onto the Regional Manager, select Help → System Information, and navigate to
the Server tab. Use the value displayed in the Official Fully Qualified Domain Name
(FQDN) field.
l
Use the nnmofficialfqdn.ovpl command.
Note: If you want NNMi to use secure sockets layer encryption (HTTPS) to access this
Regional NNMi management server, the value must match the hostname as
specified in that server's SSL Certificate. For information about establishing the
required trust relationship, see the "Global Network Management" chapter in the HP
Network Node Manager i Software Deployment Reference, which is available at:
Page 57 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Attribute
Description
http://h20230.www2.hp.com/selfsolve/manuals.
NNMi uses this hostname for communication with the Regional NNMi management server
and to construct URL Actions. See "Authentication Requirements for URLs Access". See
also "Actions Provided by NNMi" (on page 30) and read about these actions:
Use
Encryption
l
Actions → Regional Manager Console (opens the NNMi console)
l
Actions → Open from Regional Manager (opens the Node form)
If disabled, NNMi uses hypertext transfer protocol (HTTP) and plain sockets to access
this Regional NNMi management server.
If enabled, NNMi uses secure sockets layer encryption (HTTPS/SSL) to access this
Regional NNMi management server.
HTTP(S)
Port
The Global Manager initiates all communication sockets. The Global Manager needs
access to the following default TCP ports on each Regional Manager:
Non-Encrypted
l
jboss.http.port = 80
l
jboss.bisocket.port = 4457
l
jboss.jmsControl.port = 4458
Encrypted
l
jboss.https.port = 443
l
jboss.sslbisocket.port = 4459
l
jboss.ssljmsControl.port = 4460
To determine the current port number configuration or change port settings, access the
Regional Manager and look in the nms-local.properties file. See the nnm.ports Reference
Page for more information.
If Use Encryption is disabled (previous attribute), enter the port number for HTTP access
to the NNMi console on the Regional NNMi management server. For example
http://<serverName>:<portNumber>/nnm/
If Use Encryption is enabled (previous attribute), enter the port number for HTTPS access
to the NNMi console on the Regional NNMi management server. For example
https://<serverName>:<portNumber>/nnm/
User
Name
Type the user name required for NNMi sign-in for the system account on this Regional
NNMi management server.
Page 58 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Attribute
Description
User
Password
Type the password for the NNMi system account on this Regional NNMi management
server.
Note: NNMi encrypts the password and displays asterisks for this attribute. If you want to
change the password, first clear the asterisks displayed in the Password attribute and
enter the new Password value.
Ordering
A numeric value. NNMi checks for configuration settings in the order you define (lowest
number first). NNMi uses the first match found for each address. Provide a unique
connection ordering number for each Regional Manager configuration.
Any duplicate Ordering numbers are checked in random order, for example that group of
Regional Manager Connections can be checked in any order during each discovery cycle.
Tip: It is recommended that ordering numbers are incremented by 10s or 100s to provide
flexibility over time.
Disconnect Communication with a Regional Manager
(NNMi Advanced - Global Network Management feature) As administrator, you can disconnect
communication between a Global Manager (NNMi management server) and a Regional Manager (another
NNMi management server within your network environment).
To disconnect communication with a Regional Manager:
1. On the Global Manager (NNMi management server), navigate to the Global Network Management
form:
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Global Network Management form.
2. Select the Regional Manager Connections tab.
3. Click the
Open icon in the row representing the configuration you want to edit.
In the Regional Manager form, delete all Connection objects:
a. Select the Connections tab.
b. Select all Connection records, and click the
Delete icon.
4. Click
Save and Close to return to the Global Network Management form. NNMi disables
communication from this Global Manager (NNMi management server) to that Regional Manager
(NNMi management server).
5. In the Regional Manager Connections tab, note the Name attribute value for that connection
configuration (case-sensitive). You need to type this text string to replace
<RegionalNNMiServerName> in a later step.
6. Click
Save and Close.
7. On the Global Manager (NNMi management server), at the command line, type the following
command (see "Delete Nodes" (on page 170) and nnmnodedelete.ovpl for more information):
Page 59 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Note: The original node records on the Regional Manager (NNMi management server) are not
affected. Only the copy of the node records will be deleted from the Global Manager's
database.
If you do not want to enter an NNMi User Name attribute value and an NNMi Password attribute
value at the command line, you can use the nnmsetcmduserpw.ovpl command to specify the valid
user name and password (instead of -u and -p). The credentials set using the
nnmsetcmduserpw.ovpl command are valid for command execution by the same user. See "Set Up
Command Line Access" (on page 273) for more information.
Windows:
%NnmInstallDir%\bin\nnmnodedelete -rm <RegionalNNMiServerName> -u
<NNMiadminUserName> -p <NNMiadminPassword>
UNIX:
/opt/OV/bin/nnmnodedelete -rm <RegionalNNMiServerName> -u <NNMiadminUserName>
-p <NNMiadminPassword>
NNMi searches the Global Manager's database for all nodes that this Regional Manager is
responsible for monitoring in your network environment. NNMi removes the node records from the
Global Manager's database (these node records represent information forwarded from the Regional
Manager). NNMi removes all associated data:
n
Any interface or IP address information belonging to a deleted node.
n
Any discovery seeds that match the name or IP address of a deleted node (unless you use the
nmnodedelete -keepSeed option).
Each Incident associated with the deleted Node is modified in the following ways, but not deleted
from the NNMi database: The Status attribute changes to Closed. The Correlation Notes indicate
the deletion of the associated node, interface, or address. The RCA State attribute changes to
FALSE. Note: Incidents generated from SNMP traps or NNM 6.x/7.x Events (received from the
deleted Node) appear in the Incident views, but remain unresolved.
To remove the Incidents from your NNMi database, follow the instructions in "Archive and Delete
Incidents" (on page 1030) to delete "Closed" Incidents. You will be deleting all "Closed" Incidents, not
just the "Closed" Incidents associated with this Regional Manager.
8. On the Global Manager (NNMi management server), remove the configuration record for this
Regional Manager.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Global Network Management form.
c. Select the Regional Manager Connections tab.
d. Select the row that represents the Regional Manager (NNMi management server) that should
no longer communicate with this NNMi management server (the Global Manager), and click
the
Delete icon.
e. Click
Save and Close.
9. NNMi no longer requests information about discovery and monitoring results from that Regional
Manager.
Note: The NNMi management server that is no longer one of the Regional Managers is still fullyfunctioning, but communication between the two NNMi management servers is now disabled.
Note: Traps from that Regional Manager are still forwarded to the Global Manager if configured to do so,
see "Configure Trap Forwarding Destinations" (on page 299). Disable any trap forwarding that you
no longer need.
Page 60 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Troubleshoot Global Network Management
(NNMi Advanced - Global Network Management feature) The Global Manager and the Regional Manager
maintain separate sets of data. Conclusions about each Node are derived from the available data and can
sometimes be different. Regional Managers forward the results of each Auto-Discovery cycle to the Global
Manager. The Regional Manager can have a Node Group filter configured to limit the amount of data that
is forwarded to the Global Manager. Filters are usually unnecessary for Global Network Management. Do
not filter out nodes that are important for connectivity in your network environment to ensure NNMi has the
data needed for accurate root cause analysis.
l
The Global Manager might know information about why a connection from one site to another is down,
but the Regional Manager just knows that the router connected to that remote site has an interface that
is down. Use Actions → Regional Manager Console to see the other perspective.
l
When troubleshooting a Node on the Global Manager, you can use Actions → Open from Regional
Manager to see the latest Node information on the Regional Manager.
(NNMi Advanced - Global Network Management feature) This group of help topics can help you
troubleshoot any problems with Global Network Management:
l
"Clock Synchronization Issues (SSO / Global Network Management)" (on page 61)
l
"Determine the State of the Connection to a Regional Manager" (on page 62)
l
"Check the Health of Global Managers and Regional Managers" (on page 63)
Watch for these Incidents (error messages):
l
"Error Messages About Regional Managers (NNMi Advanced)" (on page 64)
l
$hostName Message Queue Size Exceeded Limit
l
Forwarded Incident Rate Exceeded Limit
l
$queueName Queue Size Exceeded Limit
See also these topics in NNMi Help for Operators:
l
Is the Global Network Management Feature Enabled?
l
View the NNMi Management Servers' Domain List
Clock Synchronization Issues (SSO / Global Network Management)
(Single Sign-On and NNMi Advanced - Global Network Management feature)
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, the
UNIX (HP-UX / Linux / Solaris) tool Network Time Protocol Daemon (NTPD) or one of the available
Windows operating system tools.
Review the Global Network Management deployment choices in the HP Network Node Manager i
Software Deployment Reference (available at: http://h20230.www2.hp.com/selfsolve/manuals).
l
For clock issues when creating Regional Manager Connections, click here.
If you see the following message at the bottom of the NNMi console:
Page 61 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
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>.
l
If Regional Manager Connections break after running successfully, click here.
Perhaps the clocks have drifted apart. 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.
Determine the State of the Connection to a Regional Manager
(NNMi Advanced - Global Network Management feature) NNMi provides the Connection State attribute to
help you track the health of communication connections between Global Managers and Regional
Managers in your network environment. The table below describes each possible Connection State value.
To verify the state of the communication connection between NNMi management servers:
1. Open the NNMi console on the Global Manager (NNMi management server).
2. Navigate to the Global Network Management form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Global Network Management form.
3. Select the Regional Management Servers tab.
4. Locate the Connection State column in this view.
5. Check the Connection State value for each Regional NNMi management server.
Tip: To verify the list of Nodes being managed by each NNMi management server, see View the
NNMi Management Servers' Domain List.
Possible States for Connections to Regional NNMi Management Servers
Connection
State
Description
Not
Established
The connection configuration was recently saved, and NNMi is attempting to establish the
connection.
Partial
Connection
The connection state is transitioning between states due to a recent change in your
network environment or a change in NNMi configuration settings.
Connected
Communication between the two NNMi management servers is working properly.
Not
Connected
An error occurred and the connection failed.
Check the Regional Management Server configuration settings. Perhaps one of the
designated port numbers is not correct? See "Global Manager: Connect to a Regional
Page 62 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
Connection
Description
State
Manager" (on page 55).
Perhaps the Regional NNMi management server is currently down? See "Troubleshoot
Global Network Management" (on page 61).
Check the Health of Global Managers and Regional Managers
Do one of the following to check the health of the Global Network Management feature:
l
Log onto the Global Manager as an NNMi administrator, and open the NNMi console on the Global
Manager (NNMi management server). Click here for more information.
Do one of the following:
n
Click the Tools → NNMi System Health Report menu option to view detailed information about the
health of Global Network Management.
n
Click the Help → System Information.
i. Click the Global Network Management tab.
ii. In the Regional Managers Reporting to this Global Manager section, review the list of all
Regional Managers that report to this Global Manager:
o Name: The current value of the Name attribute for this Regional NNMi management
server (as specified in the Remote Manager Connection form).
o Connection State: The current state of communication between the Global Manager
and Regional Manager. There are four possible values:
o Not Established — A new Regional Manager Connection is not yet fully functional.
This state is brief unless NNMi encounters a problem.
o Connected — Data is flowing between the Global Manager and the Remote
Manager.
o Not connected — A previously established connection is no longer working. See
"Clock Synchronization Issues (SSO / Global Network Management)" (on page 61).
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, the UNIX (HP-UX / Linux /
Solaris) tool Network Time Protocol Daemon (NTPD) or one of the available
Windows operating system tools.
Review the Global Network Management deployment choices in the HP Network
Node Manager i Software Deployment Reference (available at:
http://h20230.www2.hp.com/selfsolve/manuals).
o Node Count: The number of nodes in the Global Manager's database that are being
managed by this Regional Manager.
l
Log onto the Regional Manager as an NNMi administrator, and open the NNMi console on the
Regional Manager (NNMi management server).click here for more information..
Do one of the following:
Page 63 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
n
Click the Tools → NNMi System Health Report menu option to view detailed information about the
health of Global Network Management.
n
Click the Help → System Information.
i. Click the Global Network Management tab.
ii. Scroll down to the Reporting to Global Managers section, and review the list of all Global
Managers that receive data from this Regional Manager:
o Name: The fully-qualified DNS hostname of the Global Manager (NNMi management
server).
Note: If you see something other than a fully-qualified DNS hostname in the Name
column, the Global Manager is down and has been down since this Regional
Manager was last restarted (see "Stop or Start an NNMi Process" (on page 45) or
"Stop or Start NNMi Services" (on page 49) for more information).
o Messages Currently in Queue: The current number of messages that need to be sent
to the Global Manager.
Messages are automatically sent to the Global Manager. If the number of messages in
the queue is continually increasing and never decreasing or if the number is
consistently over 10,000 then there may be a problem.
Note: If the Global Manager is down for maintenance for a few hours, the queue size
naturally increases until the Global Manager is back online.
Queue size over 100,000 indicates a serious issue. Consider disconnecting that global
manager and removing the subscription until the issue can be resolved..
l
NNMi administrators can use the command line on any NNMi management server to generate a report
about NNMi health. See the nnmhealth.ovpl Reference Page for more information.
There are two ways to log onto a Regional Manager:
l
Directly log onto the Regional Manager (NNMi management server).
l
From the Global Manager, select any Node being managed by the Regional Manager and click
Actions → Regional Manager Console. See "Actions Provided by NNMi" (on page 30).
Error Messages About Regional Managers (NNMi Advanced)
(NNMi Advanced - Global Network Management feature) A special set of incidents keeps the Global
Manager informed of any problems with the Regional Manager:
l
l
Licensing issues
n
License Expired
n
License Mismatch
n
License Node Count Exceeded
Application fail-over health issues
n
Nnm Cluster Failover
n
Nnm Cluster Lost Standby
n
Nnm Cluster Startup
n
Nnm Cluster Transfer
Page 64 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Connecting Multiple NNMi Management Servers (NNMi Advanced)
l
Traffic volume issues
n
Snmp Trap Limit Critical
n
Snmp Trap Limit Major
n
Snmp Trap Limit Warning
n
Trap Storm
These incidents are generated on the Regional Manager (NNMi management server). The Regional
Manager forwards a copy of these incidents to the Global Manager. NNMi dynamically closes these
incidents on the Regional Manager when the issue is resolved. The NNMi administrator for the Global
Manager (NNMi management server) must manually close the forwarded copy.
From any Incident view, you can identify the forwarding server or servers (cia.remotemgr). Use the
Custom Incident Attribute tab on the Incident form for the selected incident. NNMi uses Custom Incident
Attributes (CIAs) to attach additional information to incidents.
Page 65 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Configuring Communication Protocol
NNMi uses the following protocols to discover your network and monitor the health of your network
environment:
l
Simple Network Management Protocol (SNMPv1 and SNMPv2c)
n
Read-only queries, also known as "Get" commands.
SNMPv1 and SNMPv2c require the use of a read community string to authenticate messages that
are sent between NNMi and SNMP agents. NNMi cannot discover information about the SNMPv1
and SNMPv2c devices in your network environment until you provide the appropriate read
community strings. During discovery and monitoring, NNMi uses the read community strings you
provide in the Communication Configuration workspace. When a device is first discovered, NNMi
tries all appropriate read community strings and makes a record of the first read community string
that works. To keep network traffic to a minimum, from then on NNMi uses the recorded read
community string when communicating with that device using SNMP. If at some point the device no
longer responds to the recorded read community string, NNMi tries all appropriate read community
strings and makes a record of the first read community string that now works.
n
Write commands, also known as "Set" commands.
SNMPv1 and SNMPv2c require the use of a write community string to authenticate messages that
are sent between the nnmsnmpset.ovpl command and SNMP agents. To keep network traffic to a
minimum, NNMi tries each of the three appropriate write community strings in this order: Specific
Node, Region, Default. NNMi makes a record of the first write community string that now works.
l
SNMPv3 requires the use of user-based security model (USM) user names instead of
SNMPv1/SNMPv2c community strings to authenticate messages that are sent between NNMi and
SNMP agents. NNMi cannot discover information about the SNMPv3 devices in your network
environment until you provide the appropriate user name and authentication. During discovery and
monitoring, NNMi uses the SNMPv3 User Name attribute value and authentication that the NNMi
administrator provides in the Communication Configuration workspace. When a device is first
discovered, NNMi tries all appropriate USM user names and makes a record of the first USM user
name that works. To keep network traffic to a minimum, from then on NNMi uses the recorded SNMPv3
User Name attribute value when communicating with that device using SNMP. If at some point the
device no longer responds to the recorded SNMPv3 User Name attribute value, NNMi tries all
appropriate USM user names and makes a record of the one that now works.
l
Internet Control Message Protocol (ICMP) ping commands
Note: If NNMi discovers a device for which no SNMP authentication was provided in the Communication
Configuration workspace, that device is treated as a non-SNMP device.
You control the amount of traffic NNMi generates on your network. You can modify the settings to meet
your needs.
To configure the way NNMi uses ICMP and SNMP protocols, do the following:
1. Navigate to the Communication Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
2. Make your configuration choices. Click here for a list of choices .
3. Click
Save and Close to apply your changes.
Page 66 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Note: You control the amount of network traffic generated by NNMi by designating the Rediscovery
Interval setting (see "Adjust the Rediscovery Interval" (on page 137) for more information) and
making choices when you "Configure Monitoring Behavior" (on page 214).
Configure Default SNMP and ICMP Protocol Settings
NNMi generates network traffic using ICMP and SNMP protocols to discover and monitor your network
environment. Default settings for the use of these protocols are provided, for example timeout and retry
behavior settings.
To configure the default communication protocol settings for your environment:
1. Navigate to the Communication Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
2. Locate the Default Settings groups.
3. Make your configuration choices (see the Default SNMP Settings table and Default ICMP Settings
table).
For an explanation of how NNMi implements timeout and retry configurations, see "Timeout / Retry
Behavior Example for SNMP" (on page 72) and "Timeout / Retry Behavior Example for ICMP" (on
page 73).
4. Click
Save and Close to apply your changes.
Default SNMP Settings Attributes
Attribute
Description
Enable
SNMP
Address
Rediscovery
Note: The NNMi administrator can over-ride this setting for a Region or on a per-node
basis. See "Communication Region Form" (on page 80)and "Specific Node
Settings Form (Communication Settings)" (on page 96).
If enabled, NNMi automatically identifies which management address (SNMP agent) to
use for each device. If the initially configured address becomes unreachable, NNMi
automatically locates another SNMP agent, if possible, and changes the management
address attribute value. Click here for more information.
When NNMi first discovers a node, the seed address (provided by the NNMi
administrator) or discovered address (for non-seeded nodes) becomes the initial
Management Address of the node. After NNMi builds an inventory of all IP addresses
Page 67 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
associated with the node (see "How Spiral Discovery Works" (on page 113)), NNMi
follows a set of rules to determine which address is the best choice for each node's
Management Address:
Note: With NNMi Advanced, the NNMi administrator specifies whether NNMi prefers IPv4
or IPv6 addresses when selecting the Management Address. See the HP Network
Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals
1. NNMi ignores the following addresses when determining which Management
Address is most appropriate:
n
Any address of an administratively-down interface.
n
Any address that is virtual (HSRP/VRRP).
n
Any IPv4 Anycast Rendezvous Point IP Address 1 or IPv6 Anycast address.
n
n
Any address in the reserved loopback network range. IPv4 uses 127/24
(127.*.*.*) and IPv6 uses ::1.
Any IPv6 link-local address 2.
2. NNMi prefers loopback interfaces for management communication.
n
n
If a node has only one loopback address 3, and the associated SNMP agent
responds to NNMi, that address becomes the Management Address.
If a node supports multiple loopback addresses, NNMi queries each loopback
addresses, starting with the lowest number. NNMi uses the loopback address
with the lowest number from which the SNMP agent responds (for example,
10.16.42.197 is a lower number than 10.16.197.42).
3. If no loopback address responds, NNMi queries the last-known Management
Address (if any).
4. If no response, NNMi queries up to 10 of any remaining IP addresses in the node's
IP address inventory, starting with the lowest number. NNMi uses the address with
the lowest number from which the SNMP agent responds.
5. If no response, NNMi might be configured to repeat the sequence using SNMPv1,
SNMPv2c, or SNMPv3 in the order specified by the NNMi administrator
(Communication Configurations SNMP Minimum Security Level settings).
6. When all else fails, NNMi retains the last known Management Address (if any) and
automatically changes the State of that SNMP Agent object to Critical.
1Rendezvous Point addresses are loopback addresses used for routers in multi-cast network
configurations.
2A non-routable IPv6 unicast address only used for communication with other nodes on the same link
(LAN or VLAN). Link local addresses cannot be used for communication that must be forwarded through a
router. IPv6 auto-configuration automatically assigns a unique link local address in the fe80::/10 address
space to each IPv6-enabled interface on a system.
3The address associated with the loopback interface. The loopback interface is a virtual interface on a
device that provides a route for internal communication. Many vendors provide a specially configured
loopback for management purposes. Exact details of how loopbacks are configured varies by vendor and
model. See each device's documentation for details. NNMi identifies these loopback addresses by using
IfType 24, softwareloopback from the IANA ifType-MIB.
Page 68 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
This process is repeated during each Auto-Discovery cycle, and the Management
Address can change. For example, NNMi's inventory of addresses for the node expands,
or the current Management Address does not respond to SNMP queries due to network
problems or node reconfiguration. The NNMi administrator can prevent changes to the
management address using the Communication Configurations Enable SNMP Address
Rediscovery or Preferred Management Address setting.
If disabled, when the current management address (SNMP agent) becomes
unreachable, NNMi reclassifies the node as a non-SNMP node until the previously
configured management address is available again.
Page 69 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Enable
SNMP
GetBulk
Applies only to SNMPv2 or higher. Some devices do not respond well to multiple SNMP
OIDs requests at one time. If you have devices in your network environment that have
trouble responding to GetBulk commands, you can instruct NNMi to use Get or GetNext
instead of GetBulk.
If enabled, NNMi uses the SNMPv2 GetBulk command to gather information from
devices in your network environment.
If disabled, NNMi uses the SNMP Get or GetNext command to gather information from
devices in your network environment (requesting responses for one SNMP OID at a time).
SNMP
Timeout
(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999
milliseconds.
Time that NNMi waits for a response to an SNMP query before reissuing the request. Both
the Discovery Process and the State Poller Service use this setting. For an explanation of
how NNMi implements timeout and retry configurations, see "Timeout / Retry Behavior
Example for SNMP" (on page 72).
SNMP
Retries
Count
Maximum number of retries that NNMi issues for an SNMP query before determining the
query result to be "unresponsive". Zero means no retries. Both the Discovery Process and
the State Poller Service use this setting.
SNMP Port
Default is 161. Specifies the NNMi management server's port that NNMi uses when
generating SNMP traffic. Both the Discovery Process and the State Poller Service use this
setting.
SNMP
Proxy
Address
Optional. IP address of the your SNMP Proxy Server (for example, a proxy that gathers
data from non-SNMP devices and can use that data to respond to NNMi SNMP requests).
SNMP
Proxy Port
Optional. Port number of the your SNMP Proxy Server.
To enable a proxy, you must also provide the port number of your SNMP Proxy Server.
See SNMP Proxy Port (next attribute).
To enable a proxy, you must also provide the IP address of your SNMP Proxy Server. See
SNMP Proxy Address (previous attribute).
Page 70 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
SNMP
Minimum
Security
Level
For SNMPv1 or SNMPv2c, configure NNMi to use Community Strings in your network
environment:
l
Community Only (SNMPv1)
NNMi tries only SNMPv1 settings.
l
Community Only (SNMPv1 or v2c)
NNMi first tries to use SNMPv2c settings, and, if that fails, NNMi tries SNMPv1 settings.
l
Community
NNMi first tries to use SNMPv2c settings, and, if that fails, NNMi tries SNMPv1 settings.
If both SNMPv2c and SNMPv1 fail, NNMi tries SNMPv3 settings if any are available.
For SNMPv3, configure NNMi to use the User-based Security Module (USM) level of
security required in your network environment (if your environment also uses
SNMPv1/SNMPv2c, select Community):
l
No Authentication, No Privacy
l
Authentication, No Privacy
l
Authentication, Privacy
See "Timeout / Retry Behavior Example for SNMP" (on page 72) for an explanation of
NNMi behavior with each of these choices.
Note: NNMi needs to know which SNMPv1 or SNMPv2c community strings (read/write) are used in your
environment (see "Configure Default Community Strings (SNMPv1 or SNMPv2c)" (on page 73)) and
which SNMPv3 USM settings are used in your environment (see "Configure Default SNMPv3
Settings" (on page 76)).
Default ICMP Settings
Attribute
Description
ICMP
Timeout
(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999
milliseconds.
Time that NNMi waits for a response to an ICMP query before reissuing the request. For an
explanation of how NNMi implements timeout and retry configurations, see "Timeout / Retry
Behavior Example for ICMP" (on page 73).
ICMP
Retries
Count
Maximum number of retries that NNMi issues for an ICMP query before logging an error. Zero
means no retries.
Related Topics:
"Configure Default Community Strings (SNMPv1 or SNMPv2c)" (on page 73)
"Configure Regions (Communication Settings)" (on page 79)
"Configure Specific Nodes (Communication Settings)" (on page 95).
Page 71 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Timeout / Retry Behavior Example for SNMP
When NNMi attempts to contact a device, your configuration settings for Timeout and Retry influence NNMi
behavior.
NNMi attempts to obtain information about a hostname/IP-address using SNMP, then waits the configured
timeout interval for a response. If not successful, NNMi increments the timeout interval before trying again.
This process repeats until one of the following is true:
l
The device responds to SNMP.
l
The maximum configured number of SNMP Retries fails. For example, if your timeout is 2 seconds and
your retry is 4:
n
NNMi attempts to communicate with a device and waits 2 seconds for a response.
n
If unsuccessful, NNMi tries again and waits 4 seconds for a response.
n
If unsuccessful, NNMi tries again and waits 6 seconds for a response.
n
If unsuccessful, NNMi tries again and waits 8 seconds for a response.
If no response, NNMi repeats this process using the next configured SNMP level.
l
NNMi exhausts all possibilities. NNMi considers the hostname/IP-address to be a non-SNMP device
until the next Discovery or Monitoring cycle.
Tip: It is best to use the same timeout/retry numbers for both ICMP and SNMP.
Your choice of SNMP Minimum Security Level determines the range of possibilities:
l
If your SNMP Minimum Security Level is Community Only (SNMPv1), NNMi uses only SNMPv1 to
locate SNMP agents.
l
If your SNMP Minimum Security Level is Community Only (SNMPv1 or v2c), NNMi cycles through the
following until successful:
SNMPv2c
SNMPv1
l
If your SNMP Minimum Security Level is Community, NNMi cycles through the following until
successful:
SNMPv2c
SNMPv1
SNMPv3 No Authentication, No Privacy settings (if any matching configurations, otherwise skip).
SNMPv3 Authentication, No Privacy settings (if any matching configurations, otherwise skip).
SNMPv3 Authentication, Privacy settings (if any matching configurations).
l
If your SNMP Minimum Security Level is No Authentication, No Privacy, NNMi cycles through the
following until successful:
SNMPv3 No Authentication, No Privacy settings (if any matching configurations at this, otherwise skip)
SNMPv3 Authentication, No Privacy settings (if any matching configurations, otherwise skip).
SNMPv3 Authentication, Privacy settings (if any matching configurations).
l
If your SNMP Minimum Security Level is Authentication, No Privacy, NNMi cycles through the
Page 72 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
following until successful:
SNMPv3 Authentication, No Privacy settings (if any matching configurations, otherwise skip).
SNMPv3 Authentication, Privacy settings (if any matching configurations).
l
If your SNMP Minimum Security Level is Authentication, Privacy, NNMi cycles through the following
until successful:
SNMPv3 Authentication, Privacy settings (if any matching configurations).
Timeout / Retry Behavior Example for ICMP
When NNMi attempts to contact a device, your configuration settings for Timeout and Retry influence NNMi
behavior.
NNMi attempts to contact the device using ICMP, then waits the configured timeout interval for a response.
If not successful, NNMi increments the timeout interval before trying again. This process repeats until one
of the following is true:
l
The device responds to ICMP.
l
The maximum configured number of ICMP Retries fails. NNMi considers the device unreachable
through ICMP until the next Discovery or Monitoring cycle. For example, if your timeout is 2 seconds
and your retry is 4:
n
NNMi attempts to communicate with a device and waits 2 seconds for a response.
n
If unsuccessful, NNMi tries again and waits 4 seconds for a response.
n
If unsuccessful, NNMi tries again and waits 6 seconds for a response.
n
If unsuccessful, NNMi tries again and waits 8 seconds for a response.
Tip: It is best to use the same timeout/retry numbers for both ICMP and SNMP.
Configure Default Community Strings (SNMPv1 or SNMPv2c)
Use the Default Community Strings tab to provide default SNMPv1 and SNMPv2c passwords. For each
address, NNMi checks the communication configuration settings in this order: communication protocols for
Specific Nodes, communication protocols for Network Regions, and if no match is found, NNMi tries these
default community strings. If NNMi discovers a device for which no SNMP settings are provided, that
device is treated as a Non-SNMP device.
During initial discovery, NNMi tries many community strings until a match is found. After a match is
identified for a node, the information is recorded to prevent future authentication errors.
Note: If you provide a read community string for a specific device, NNMi honors your choice and does not
try any Region or Default community strings for that device.
NNMi uses SNMP read-only queries (Get commands) for ongoing discovery and monitoring of your
network environment. SNMP read community strings are the validation passwords used to authenticate
messages sent from NNMi to an SNMP agent. NNMi uses SNMP to gather useful information about the
devices in your network environment. After receiving an SNMP request, an SNMP agent compares the
read community string in the request to the read community strings that are configured for that SNMP
agent. The SNMP agent responds to the request only when the request is accompanied by a valid
community string.
During NNMi installation, any community strings that were provided are automatically stored in the table
on the Default Community Strings tab.
Page 73 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Provide any number of additional community strings that are used broadly in your environment (for
example, by default). The order in which your read community string settings appear in the table does not
matter. NNMi checks all Default read community strings in parallel.
Tip: Having a large number of default community strings can negatively impact discovery performance.
Instead of entering many default community strings, consider fine tuning the community string
configuration for particular areas of your network by using the Regions or Specific Nodes settings.
NNMi uses the SNMPv2 settings to discover the SNMPv2 information about your network. This also
determines whether NNMi receives or discards incoming SNMPv2 traps. Click here for more information.
l
If the incoming trap's Source Node object or Source Object (such as card or interface) has not yet been
discovered by NNMi, see "Handle Unresolved Incoming Traps" (on page 428) for additional
information. See also "Configure Network Devices to Send SNMP Notifications to NNMi" (on page
424).
l
If the Source Node or Source Object of the incoming trap has been discovered by NNMi using
SNMPv2c or SNMPv1, NNMi accepts incoming traps from SNMPv2c or SNMPv1, but NNMi discards
incoming traps from SNMPv3.
l
NNMi discards traps that have no Incident Configuration or with an Incident Configuration set to
Disabled.
l
If either the Source Node or Source Object has Management Mode set to Not Managed or Out of
Service in the NNMi database, NNMi always discards the incoming trap. See "Understand the Effects
of Setting the Management Mode to Not Managed or Out of Service " (on page 255).
NNMi provides the Management Mode workspace so that you can quickly view lists of all nodes,
interfaces, cards, addresses, or node components that NNMi is not currently discovering or monitoring.
For information about these views:
Note: If you want the NNMi management server to forward SNMPv2 traps to other machines in your
network environment, see "Configuring Trap Forwarding" (on page 295) for additional configuration
steps.
To configure default SNMPv1 or SNMPv2c community strings for your environment:
1. Navigate to the Communication Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
2. Locate the Default SNMPv1/v2 Community Strings tab.
3. To provide a default read community string, navigate to the Read Community Strings table and do
one of the following:
n
To establish a community string setting, click the
New icon. In the Default Read Community
String form, provide the required information (see table).
n
To edit a community string setting, click the
Open icon in the row representing the community
string setting you want to edit. In the Default Read Community String form, provide the required
information (see table).
n
To delete a community string setting, select a row and click the
Delete icon.
4. To provide a default write community string, navigate to the Write Community String attribute (see
table).
Page 74 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
5. Click
Save and Close to return to the Communication Configuration form.
6. Click
Save and Close to apply your changes.
Default SNMPv1 or SNMPv2c Community Strings
Attribute
Description
Read
Community
String
The SNMPv1 or SNMPv2c "get" (read-only) community string that is used for this region
(case-sensitive).
Many proxy vendors use the read community string for specifying remote target
information. NNMi supports substitution parameters within read community strings for
SNMPv1 or SNMPv2 proxy environments. Click here for more information.
Copy and paste these codes at the end of your read community string to provide the values
required by your proxy environment. NNMi substitutes the actual attribute values from the
NNMi database at runtime:
${contextName} = Used for specifying VLAN context for switches (VLAN associated with
the remote target node)
${managementAddress} = Node form, Management Address attribute value (the remote
target node)
${snmpPort} = SNMP Agent form, UDP Port attribute value (SNMP agent associated with
the remote target node)
Write
Community
String
The SNMPv1 or SNMPv2c "set" (write) community string that is used for this region (casesensitive).
Optional. For use with the nnmsnmpset.ovpl command line tool.
SNMPv1 and SNMPv2c require that you know the SNMP agent's write community string
before you can change settings on any device. The nnmsnmpset.ovpl command can use
the value you provide here, rather than requiring that you type the write community string
each time you invoke the command.
Default Read Community String Form
For each IP address, NNMi checks the communication configuration settings in this order: communication
protocols for Specific Devices, communication protocols for Network Regions, and if no match is found,
NNMi tries the default community strings. If NNMi discovers a device for which no community string is
provided, that device is treated as a Non-SNMP device.
To provide a default community string for your environment:
1. Navigate to the Default Read Community String form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
c. Navigate to the Default SNMPv1/v2 Community Strings tab.
d. Navigate to the Read Community Strings table.
e. Do one of the following:
Page 75 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
o To establish a community string setting, click the
New icon, and continue.
o To edit a community string setting, select a row, click the
Open icon in the row
representing the configuration you want to edit, and continue.
2. Provide the read community string (see table).
Provide any number of additional SNMPv1 or SNMPv2c read community strings that are used
broadly in your environment (for example, by default). The order in which your read community string
settings appear in this table does not matter. NNMi checks all Default read community strings in
parallel.
3. Click either:
n
Save and Close to return to the Communication Configuration form.
n
Save and New to add another community string.
4. Click
Save and Close to apply your changes.
Default Read Community String
Attribute
Description
Read
Community
String
The SNMP "get" (read-only) community string that is used in your network environment
(case-sensitive).
Many proxy vendors use the read community string for specifying remote target
information. NNMi supports substitution parameters within read community strings for
SNMPv1 or SNMPv2 proxy environments. Click here for more information.
Copy and paste these codes at the end of your read community string to provide the values
required by your proxy environment. NNMi substitutes the actual attribute values from the
NNMi database at runtime:
${contextName} = Used for specifying VLAN context for switches (VLAN associated with
the remote target node)
${managementAddress} = Node form, Management Address attribute value (the remote
target node)
${snmpPort} = SNMP Agent form, UDP Port attribute value (SNMP agent associated with
the remote target node)
Configure Default SNMPv3 Settings
Use the Default SNMPv3 Settings tab to provide default SNMPv3 user-based security model (USM)
settings. For each address, NNMi checks the communication configuration settings in this order:
communication protocols for Specific Nodes, communication protocols for Network Regions, and if no
match is found, NNMi tries these default user-based security model (USM) settings. If NNMi discovers a
device for which no SNMP settings are provided, that device is treated as a Non-SNMP device.
During initial discovery, NNMi tries many SNMP configuration settings until a match is found. After a match
is identified for a Node, the information is recorded to prevent future authentication errors.
Note: If you provide SNMPv3 user-based security model (USM) settings for a specific device, NNMi honors
your choice and does not try any Region or Default settings for that device.
Page 76 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
NNMi uses SNMP queries for ongoing discovery and monitoring of your network environment. SNMPv3
user-based security model (USM) settings are used to authenticate messages sent from NNMi to an SNMP
agent. NNMi uses SNMP to gather useful information about the devices in your network environment. After
receiving an SNMP request, an SNMP agent compares the SNMPv3 user-based security model (USM)
settings in the request to the SNMPv3 user-based security model (USM) settings that are configured for
that SNMP agent. The SNMP agent responds to the request only when the request is accompanied by
valid SNMPv3 user-based security model (USM) settings.
Provide any number of additional SNMPv3 user-based security model (USM) settings that are used
broadly in your environment (for example, by default). The order in which your SNMPv3 user-based
security model (USM) settings appear in this table does not matter. NNMi checks all Default SNMPv3
Settings at a particular security level in parallel.
NNMi uses Default SNMPv3 user-based security model (USM) settings to access devices.
To view the current list of default SNMPv3 USM settings:
1. Navigate to the Default SNMPv3 Settings tab.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Default SNMPv3 Settings tab.
2. The displayed table lists the Unique Name of each default SNMPv3 USM setting.
Note: NNMi tries to use the Specific Node SNMPv3 Settings. If none match, NNMi tries the Region
SNMPv3 Settings. If none match, NNMi tries the default SMNPv3 settings provided here.
3. You can do the following:
n
To establish a new setting, click the
77).
Click
n
Save and Close to return to the Default SNMPv3 Settings form.
To edit an existing setting, select a row, click the
form" (on page 77).
Click
n
New icon. See "Default SNMPv3 Settings form" (on page
Open icon. See "Default SNMPv3 Settings
Save and Close to return to the Default SNMPv3 Settings form.
To delete an existing setting from the Default list, select a row and click the
Delete icon.
Note: The record remains in the database for possible use elsewhere and is simply removed
from the Default list.
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Default SNMPv3 Settings form
NNMi can use SNMPv3 user-based security model (USM) settings to access devices.
NNMi tries to use the current SNMPv3 Settings attribute value from Specific Node Settings. If none match,
NNMi tries the Region SNMPv3 Settings. If none match, NNMi tries the default SMNPv3 settings provided
here.
To configure a Default SNMPv3 Setting:
Page 77 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
1. Navigate to the Default SNMPv3 Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
c. Navigate to the Default SNMPv3 Settings tab.
d. Do one of the following:
o To create default SNMPv3 Setting definition, click the
o To edit a default SNMPv3 Setting, select a row, click the
2. Click the SNMPv3 Settings
menu:
New icon.
Open icon.
Lookup icon and select one of the options from the drop-down
n
Quick View to display summary information for the currently configured (selected) SNMPv3
Setting name.
n
Quick Find to view and select from the list of all existing SNMPv3 Settings (for more
information see "Use the Quick Find Window" (on page 28)).
n
Open to display the details of the currently configured (selected) SNMPv3 Setting (see
"SNMPv3 Settings Form" for more information).
n
New to create a new SNMPv3 Setting (see "SNMPv3 Settings Form" for more information).
3. Click
Save and Close to return to the Default SNMPv3 Settings form.
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Configure the Default Device Credentials (NNM iSPI NET)
HP Network Node Manager iSPI Network Engineering Toolset Software uses the Default Credentials
setting to access devices when running Diagnostics either automatically or when the Actions → Run
Diagnostics (iSPI NET only) option is used. (See "Configure Diagnostics for an Incident (NNM iSPI NET)"
(on page 417) and Node Form: Diagnostics Tab for more information.)
NNM iSPI NET uses Secure Shell (SSH) to establish a secure connection with devices in your network
environment, using the credentials provided here. If the SSH attempt fails, If the SSH attempt fails, NNMi
uses Telnet protocol as the communication method.
To provide the default credentials setting:
1. Navigate to the Default Device Credentials form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Default Device Credentials tab.
d. Do one of the following:
o To establish a credential setting, click the
New icon, and continue.
o To edit a credential setting, select a row, click the
Open icon, and continue.
Page 78 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
o To delete a credential setting, select a row and click the
Delete icon
2. Provide one setting for the default attribute values (see table).
Caution: Populate only one row in this table.
Note: NNMi tries to use the Specific Node Device Credentials. If none match, NNMi tries the Region
Device Credentials. If none match, NNMi tries the default credential settings provided here.
3. Click
Save and Close to return to the Communication Configuration form.
4. Click
Save and Close to apply your changes.
Default Device Credential Attributes
Attribute
Description
User
Name
Type the user name that you want NNMi to use for logging into devices by default (when no
Region or Specific Node settings work).
Password
Type the password that you want NNMi to use for logging into devices by default (when no
Region or Specific Node settings work).
Note: NNMi encrypts the password and displays asterisks for this attribute. If you want to
change the password, first clear the asterisks displayed in the Password attribute and
enter the new Password value.
Configure Regions (Communication Settings)
Configuring communication protocols for regions is optional.
Note: If you provide an SNMPv1 or SNMPv2c read community string or an SNMPv3 USM Setting for a
specific device, NNMi honors your choice and does not try any Region or Default settings for that
device.
Use the Regions tab to fine tune communication protocol usage and settings for particular regions of your
network (for example, buildings, floors within those buildings, workgroups within a particular floor, or
private IP addresses 1). When you leave a field blank in a region definition, NNMi uses the next
applicable configuration setting in the following order:
l
The value for each field as defined in the first Region definition that matches, Regions are checked
according to the Ordering number. The match with the lowest Ordering number applies.
l
If no Region definition provides a value for an attribute, the default value is used.
Note: NNMi enables you to set up one or more SNMP Proxy Servers when an SNMP node is otherwise
unreachable (for example, when a node you want to manage is behind a firewall). To enable NNMi
to use the SNMP Proxy Server, when you configure communication protocols for network regions,
you must include the IP address and port number on the SNMP Proxy Server. See "Communication
Region Form" (on page 80) for more information.
If your communication protocol usage is too complex for Region definitions, see "Configure Specific Nodes
(Communication Settings)" (on page 95).
1These are IPv4 addresses that can be reused in home and office local area networks (LANs). Following
the standards set by RFC 1918 and RFC 4193 (10.*.*.*, 169.254.*.*, 172.16-31.*.*, and 192.168.*.*)
Page 79 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
To configure communication protocols for a particular region of your network:
1. Navigate to the Communication Region form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
c. Navigate to the Regions tab.
d. Do one of the following:
o To establish a region definition, click the
New icon, and continue.
o To edit a region definition, select a row, click the
Open icon, and continue.
o To delete a region definition, select a row and click the
Delete icon.
2. Provide the required information. Define the regions with wildcard address, wildcard device names,
or literal addresses and names . See "Communication Region Form" (on page 80).
3. Click
Save and Close to return to the Communication Configuration form.
4. Click
Save and Close to apply your changes.
Related Topics:
"Configure Default SNMP and ICMP Protocol Settings" (on page 67)
"Configure Default Community Strings (SNMPv1 or SNMPv2c)" (on page 73)
"Configure Specific Nodes (Communication Settings)" (on page 95)
Communication Region Form
To configure communication regions:
1. Navigate to the Communication Region form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
c. Navigate to the Regions tab.
d. Do one of the following:
o To establish a region definition, click the
New icon, and continue.
o To edit a region definition, select a row, click the
Open icon, and continue.
2. Provide the basic communication region definition (see the Regional Basic Settings table, Regional
SNMP Settings table, and Regional ICMP Settings table).
3. Make your configuration choices. Click here for a list of choices .
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Page 80 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Regional Basic Settings
Attribute
Description
Name
A name for this region.
Ordering
A numeric value. NNMi checks for configuration settings in the order you define (lowest
number first). NNMi uses the first match found for each address.
No duplicate Ordering numbers are allowed. Each Communication Region ordering
number must be unique.
Tip: It is recommended that ordering numbers are incremented by 10s or 100s to provide
flexibility when adding new regions over time.
Description
Optional. Provide any description that would be useful for communication purposes within
your team.
Type a maximum of 255 characters. Alpha-numeric, spaces, and special characters (~ ! @
# $ % ^ & * ( ) _+) are allowed.
Regional SNMP Settings
Attribute
Description
Enable SNMP
Communication
If enabled, the Discovery Process and State Poller Service generate network traffic
with SNMP protocol to discover and monitor your network devices in this region.
If disabled, NNMi does not generate any SNMP traffic on your network in this
region.
Caution: At least one IP Address in each node must have SNMP enabled, otherwise
no SNMP data is collected from that Node. With no SNMP data, Spiral
Discovery interprets each IP Address as a separate node, Causal Engine
calculates Status based only on IP address State, previously discovered
Interfaces show a State attribute value of "Not Polled" and a Status attribute
value of "No Status" with the Interface map-symbol color set to beige, and no
new Interfaces are discovered.
Note: See "Monitoring Network Health" (on page 213) for information about
enabling/disabling SNMP communication specifically for the State Poller
Service.
Enable SNMP
Address
Rediscovery
Page 81 of 1087
Note: The NNMi administrator can over-ride this setting on a per-node basis. See
"Specific Node Settings Form (Communication Settings)" (on page 96).
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
If enabled, NNMi automatically identifies which management address (SNMP
agent) to use for each device. If the initially configured address becomes unreachable,
NNMi automatically locates another SNMP agent, if possible, and changes the
management address attribute value. Click here for more information.
When NNMi first discovers a node, the seed address (provided by the NNMi
administrator) or discovered address (for non-seeded nodes) becomes the initial
Management Address of the node. After NNMi builds an inventory of all IP addresses
associated with the node (see "How Spiral Discovery Works" (on page 113)), NNMi
follows a set of rules to determine which address is the best choice for each node's
Management Address:
Note: With NNMi Advanced, the NNMi administrator specifies whether NNMi prefers
IPv4 or IPv6 addresses when selecting the Management Address. See the HP
Network Node Manager i Software Deployment Reference, which is available
at: http://h20230.www2.hp.com/selfsolve/manuals
1. NNMi ignores the following addresses when determining which Management
Address is most appropriate:
n
Any address of an administratively-down interface.
n
Any address that is virtual (HSRP/VRRP).
n
Any IPv4 Anycast Rendezvous Point IP Address 1 or IPv6 Anycast address.
n
n
Any address in the reserved loopback network range. IPv4 uses 127/24
(127.*.*.*) and IPv6 uses ::1.
Any IPv6 link-local address 2.
2. NNMi prefers loopback interfaces for management communication.
n
n
If a node has only one loopback address 3, and the associated SNMP agent
responds to NNMi, that address becomes the Management Address.
If a node supports multiple loopback addresses, NNMi queries each
loopback addresses, starting with the lowest number. NNMi uses the
loopback address with the lowest number from which the SNMP agent
responds (for example, 10.16.42.197 is a lower number than 10.16.197.42).
3. If no loopback address responds, NNMi queries the last-known Management
Address (if any).
4. If no response, NNMi queries up to 10 of any remaining IP addresses in the
1Rendezvous Point addresses are loopback addresses used for routers in multi-cast network
configurations.
2A non-routable IPv6 unicast address only used for communication with other nodes on the same link
(LAN or VLAN). Link local addresses cannot be used for communication that must be forwarded through a
router. IPv6 auto-configuration automatically assigns a unique link local address in the fe80::/10 address
space to each IPv6-enabled interface on a system.
3The address associated with the loopback interface. The loopback interface is a virtual interface on a
device that provides a route for internal communication. Many vendors provide a specially configured
loopback for management purposes. Exact details of how loopbacks are configured varies by vendor and
model. See each device's documentation for details. NNMi identifies these loopback addresses by using
IfType 24, softwareloopback from the IANA ifType-MIB.
Page 82 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
node's IP address inventory, starting with the lowest number. NNMi uses the
address with the lowest number from which the SNMP agent responds.
5. If no response, NNMi might be configured to repeat the sequence using
SNMPv1, SNMPv2c, or SNMPv3 in the order specified by the NNMi administrator
(Communication Configurations SNMP Minimum Security Level settings).
6. When all else fails, NNMi retains the last known Management Address (if any)
and automatically changes the State of that SNMP Agent object to Critical.
This process is repeated during each Auto-Discovery cycle, and the Management
Address can change. For example, NNMi's inventory of addresses for the node
expands, or the current Management Address does not respond to SNMP queries due
to network problems or node reconfiguration. The NNMi administrator can prevent
changes to the management address using the Communication Configurations
Enable SNMP Address Rediscovery or Preferred Management Address setting.
If disabled, when the current management address (SNMP agent) becomes
unreachable, NNMi reclassifies the node as a non-SNMP node until the previously
configured management address is available again.
Page 83 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Enable SNMP
GetBulk
Applies only to SNMPv2 or higher. Some devices do not respond well to multiple
SNMP OIDs requests at one time. If you have devices in your network environment that
have trouble responding to GetBulk commands, you can instruct NNMi to use Get or
GetNext instead of GetBulk.
If enabled, NNMi uses the SNMPv2 GetBulk command to gather information from
devices in this Region of your network environment.
If disabled, NNMi uses the SNMP Get or GetNext command to gather information
from devices in this Region of your network environment (requesting responses for
one SNMP OID at a time).
SNMP Timeout
(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999
milliseconds.
Time that NNMi waits for a response to an SNMP query before reissuing the request.
Both the Discovery Process and the State Poller Service use this setting in this region.
For an explanation of how NNMi implements timeout and retry configurations, see
"Timeout / Retry Behavior Example for SNMP" (on page 72).
SNMP Retries
Count
Maximum number of retries that NNMi issues for an SNMP query before determining
the query result to be "unresponsive". Zero means no retries. Both the Discovery
Process and the State Poller Service use this setting in this region.
SNMP Port
Default is 161. Specifies the management server's port that NNMi uses when
generating SNMP traffic. Both the Discovery Process and the State Poller Service use
this setting in this region.
SNMP Proxy
Address
Optional. IP address of the your SNMP Proxy Server (for example, a proxy that gathers
data from non-SNMP devices and can use that data to respond to NNMi SNMP
requests).
To enable a proxy, you must also provide the port number of your SNMP Proxy Server.
See SNMP Proxy Port (next attribute).
SNMP Proxy
Port
Optional. Port number of the your SNMP Proxy Server.
To enable a proxy, you must also provide the IP address of your SNMP Proxy Server.
See SNMP Proxy Address (previous attribute).
Page 84 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
SNMP
Minimum
Security Level
For SNMPv1 or SNMPv2c, configure NNMi to use Community Strings in your network
environment:
l
Community Only (SNMPv1)
NNMi tries only SNMPv1 settings.
l
Community Only (SNMPv1 or v2c)
NNMi first tries to use SNMPv2c settings, and, if that fails, NNMi tries SNMPv1
settings.
l
Community
NNMi first tries to use SNMPv2c settings, and, if that fails, NNMi tries SNMPv1
settings. If both SNMPv2c and SNMPv1 fail, NNMi tries SNMPv3 settings if any are
available.
For SNMPv3, configure NNMi to use the User-based Security Module (USM) level of
security required in your network environment (if your environment also uses
SNMPv1/SNMPv2c, select Community):
l
No Authentication, No Privacy
l
Authentication, No Privacy
l
Authentication, Privacy
See "Timeout / Retry Behavior Example for SNMP" (on page 72) for an explanation of
NNMi behavior with each of these choices.
Regional ICMP Settings
Attribute
Description
Enable ICMP
Communication
If
enabled, NNMi generates network traffic with ICMP protocol in this region.
If
disabled, NNMi does not generate any ICMP traffic on your network in this region:
l
Addresses in this Region (both previously discovered and newly discovered) have
a State attribute value of "Not Polled" and a Status attribute value of "No Status"
with the IP Address map-symbol color set to beige.
l
Nodes with all IP addresses and interfaces showing a Status attribute value of "No
Status" have a map-symbol background shape color set to beige. However, it is
possible for a node to have IP addresses in multiple regions with multiple Status
values.
Note: See "Monitoring Network Health" (on page 213) for information about
enabling/disabling ICMP communication specifically for the State Poller
Service.
ICMP Timeout
(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999
milliseconds.
Time that NNMi waits for a response to an ICMP query before reissuing the request in
this region. For an explanation of how NNMi implements timeout and retry
configurations, see "Timeout / Retry Behavior Example for ICMP" (on page 73).
ICMP Retries
Count
Page 85 of 1087
Maximum number of retries that NNMi issues for an ICMP query in this region before
logging an error. Zero means no retries.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Configure Address Ranges for Regions
To configure an address range for this region:
1. Navigate to the Region Included Address Range form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Regions tab.
d. Do one of the following:
o To establish a region definition, click the
New icon, and continue.
o To edit a region definition, select a row, click the
Open icon, and continue.
e. In the Communication Region form, navigate to the Included Address Regions tab.
f. Do one of the following:
o To establish an address range setting, click the
New icon, and continue.
o To edit an address range setting, select a row, click the
Open icon, and continue.
o To delete an address range setting, select a row and click the
Delete icon.
2. Provide address range definition (see table).
If you provide multiple IP address ranges for a region, each device must pass at least one to meet the
criteria.
Tip: If you provide both IP address ranges and hostname wildcards, each device must pass at least
one in either category (not both) to meet the criteria.
3. Click
Save and Close to return to the Communication Region form.
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Address Range Definition Attribute
Attribute
Description
IP
Range
To specify a range of IP addresses for this Communications Region, use one of the
following. Pick one address notation style, combinations of wildcards and CIDR notation are
not allowed within one address range. You can provide multiple address range settings:
l
IPv4 address wildcard notation.
An IPv4 Address range is a modified dotted-notation where each octet is one of the
following:
n
A specific octet value between 0 and 255
n
A low-high range specification for the octet value (for example, "112-119")
n
An asterisk (*) wildcard character which is equivalent to the range expression "0-255"
Page 86 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Note: The following two IPv4 addresses are considered invalid: 0.0.0.0 and
127.0.0.0
Examples of valid IPv4 address wildcards include:
10.1.1.*
10.*.*.*
10.1.1.1-99
10.10.50-55.*
10.22.*.4
10.1-9.1-9.1-9
l
IPv4 Classless Inter-Domain Routing (CIDR) notation.
The CIDR notation specifies the number of consecutive bits in the IPv4 address that must
match.
For example, 10.2.120.0/21
Note: NNMi does not support CIDR subnet mask notation such as,
10.2.120.0/255.255.248.0
Example IPv4 Prefix Length Values
Number of Usable IPv4 Addresses
28
14 (16-2=14)*
29
6 (8-2=6)*
30
2 (4-2=2)*
31
2
* Two IPv4 addresses are reserved in each subnet. The first IPv4 address is used for the
network itself and the last IPv4 address is reserved for broadcast.
l
IPv6 address wildcard notation
Separate each 16-bit value of the IPv6 address with a colon. The 16-bit value can be any
of the following:
n
A specific hexadecimal value between 0 and FFFF (case insensitive).
n
A low-high range specification of the hexadecimal value (for example, 1-1fe).
n
An asterisk (*) wildcard character (equivalent to the range expression 0-ffff).
Note: The standard IPv6 short-hand notation (::) is allowed to express one or more 16bit elements of zero (0) values. However, the mixed IPv6/IPv4 dot-notation (for
example, 2001:d88::1.2.3.4) is not allowed as an IPv6 address range.
Valid examples of ranges in modified IPv6 address notation include the following:
2001:D88:0:A00-AFF:*:*:*:*
2001:D88:1:*:*:*:*:*
2001:D88:2:0:a07:ffff:0a01:3200-37ff
l
IPv6 Classless Inter-Domain Routing (CIDR) notation
The CIDR notation specifies the number of consecutive bits in the IPv6 address that must
match.
1080:0:a00::/44 (equivalent to modified IPv6 address notation 1080:0:a00-
Page 87 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
a0f:*:*:*:*:*)
For example, valid IPv6 address ranges in CIDR notation include the following:
2001:d88:0:a00::/56 (equivalent to modified IPv6 address notation
2001:D88:0:A00-AFF:*:*:*:*)
2001:d88:1::/48 (equivalent to modified IPv6 address notation
2001:D88:1:*:*:*:*:*)
Page 88 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Configure Hostname Filters for Regions
Define the Communication Region with hostname patterns.
To establish a Hostname Filter setting:
1. Navigate to the Region Hostname Filter form.
n
From the workspace navigation panel, select the Configuration workspace.
n
Select the Communication Configuration.
n
Navigate to the Regions tab.
n
Do one of the following:
o To create a region definition, click the
New icon.
o To edit a region definition, select a row, click the
Open icon.
n
In the Communication Region form, access the Hostname Filters tab.
n
Do one of the following:
o To create a hostname wildcard definition, click the
New icon.
o To edit a hostname wildcard definition, select a row, click the
Open icon.
o To delete a hostname wildcard setting, select a row and click the
Delete icon.
2. Type an appropriate hostname filter (see table).
If you provide multiple hostname wildcard expressions for a region, each device must pass at least
one to meet the criteria for the Region.
Tip: If you provide both hostname wildcards and IP address ranges, each device must pass at least
one in either category (not both) to meet the criteria for the Region.
3. Click
Save and Close to return to the Communication Region form.
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes. See "Discovering Your Network" (on page 112) and
Verify Device Configuration Details.
Node Hostname Filter Definition
Attribute
Description
Hostname
Filter
Enter a wildcard expression using the following characters as wildcards:
l
? = one character
l
* = multiple characters
Wildcard expressions are not case-sensitive. So a wildcard of ABC* would match devices
with hostnames beginning with ABC*, abc*, and Abc*
Caution: The Hostname attribute value on the Node form of the discovered node must
match (not case-sensitive) what is entered here.
NNMi follows a set of rules to dynamically generate the value stored in the NNMi database
for each Node's Hostname. Click here for details.
Page 89 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Note: The actual Hostname might be converted to all uppercase or all lowercase before it is
added to the NNMi database (depending on how the NNMi administrator configured
settings in the nms-topology.properties file). See the information about the nmstopology.properties file in the HP Network Node Manager i Software
Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals.
l
If the Node supports SNMP, NNMi requests the Hostname using the IP Address of the
associated SNMP agent (the Management Address attribute value on the Node form).
If the NNMi administrator chooses
Communication Configuration:
n
If the SNMP Agent does not respond, NNMi checks for another Management
Address to request the Hostname, and the Hostname could change.
n
If the SNMP Agent associated with the node changes, the Management Address and
Hostname could change.
If the NNMi administrator disables
Communication Configuration:
l
Enable SNMP Address Rediscovery in the
Enable SNMP Address Rediscovery in the
n
If the SNMP Agent does not respond, NNMi uses the previously gathered
Management Address attribute value to request the Hostname.
n
If the SNMP Agent associated with the node changes, NNMi uses the previously
gathered Management Address attribute value to request the Hostname.
If the Node does not support SNMP, no Management Address is available. NNMi
requests a Hostname starting with the lowest IP Address associated with the node (a
Discovery Seed value or an IP address value gathered from a neighboring device).
NNMi uses the first Hostname provided. The Hostname might change during a future
discovery cycle.
Configure SNMPv1/v2 Community Strings for Regions
If more than one SNMPv1 or SNMPv2c "get" community string is used within this region, repeat this step
any number of times. Order does not matter because all community strings defined for this Region are
checked in parallel.
During initial discovery, NNMi tries many community strings until a match is found. After a match is
identified for a Node, the information is recorded to prevent future authentication errors.
NNMi uses the SNMPv2 settings to discover the SNMPv2 information about your network. This also
determines whether NNMi receives or discards incoming SNMPv2 traps. Click here for more information.
l
If the incoming trap's Source Node object or Source Object (such as card or interface) has not yet been
discovered by NNMi, see "Handle Unresolved Incoming Traps" (on page 428) for additional
information. See also "Configure Network Devices to Send SNMP Notifications to NNMi" (on page
424).
l
If the Source Node or Source Object of the incoming trap has been discovered by NNMi using
SNMPv2c or SNMPv1, NNMi accepts incoming traps from SNMPv2c or SNMPv1, but NNMi discards
incoming traps from SNMPv3.
Page 90 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
l
NNMi discards traps that have no Incident Configuration or with an Incident Configuration set to
Disabled.
l
If either the Source Node or Source Object has Management Mode set to Not Managed or Out of
Service in the NNMi database, NNMi always discards the incoming trap. See "Understand the Effects
of Setting the Management Mode to Not Managed or Out of Service " (on page 255).
NNMi provides the Management Mode workspace so that you can quickly view lists of all nodes,
interfaces, cards, addresses, or node components that NNMi is not currently discovering or monitoring.
For information about these views:
Note: If you want the NNMi management server to forward SNMPv2 traps to other machines in your
network environment, see "Configuring Trap Forwarding" (on page 295) for additional configuration
steps.
To provide a community string for this region:
1. Navigate to the Communication Region form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Regions tab.
d. Do one of the following:
o To establish a region definition, click the
New icon, and continue.
o To edit a region definition, select a row, click the
Open icon, and continue.
2. In the Communication Region form, navigate to the SNMPv1/v2 Community Strings tab.
3. To provide a read community string, navigate to the Read Community Strings table and do one of
the following:
Note: If you do not provide any community strings, NNMi uses the Default Community Strings.
n
To establish a community string setting, click the
information (see table).
n
To edit a community string setting, select a row, click the
information (see table)
n
To delete a community string setting, select a row and click the
New icon, and provide the required
Open icon, and provide the required
Delete icon
4. To provide a write community string for this region, navigate to the Write Community String attribute
(see table).
Note: If you do not provide any community strings, NNMi uses the Default Community Strings.
5. Click
Save and Close to return to the Communication Region form.
6. Click
Save and Close to return to the Communication Configuration form.
7. Click
Save and Close to apply your changes.
Page 91 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
SNMPv1 or SNMPv2c Community String for this Region
Attribute
Description
Read
Community
String
The SNMPv1 or SNMPv2c "get" (read-only) community string that is used for this region
(case-sensitive).
Tip: If no values appear in this table, the default settings are used (see "Configure Default
Community Strings (SNMPv1 or SNMPv2c)" (on page 73)).
Many proxy vendors use the read community string for specifying remote target
information. NNMi supports substitution parameters within read community strings for
SNMPv1 or SNMPv2 proxy environments. Click here for more information.
Copy and paste these codes at the end of your read community string to provide the values
required by your proxy environment. NNMi substitutes the actual attribute values from the
NNMi database at runtime:
${contextName} = Used for specifying VLAN context for switches (VLAN associated with
the remote target node)
${managementAddress} = Node form, Management Address attribute value (the remote
target node)
${snmpPort} = SNMP Agent form, UDP Port attribute value (SNMP agent associated with
the remote target node)
Write
Community
String
Optional. For use with the nnmsnmpset.ovpl command line tool.
SNMPv1 and SNMPv2c require that you know the SNMP agent's write community string
before you can change settings on any device. The nnmsnmpset.ovpl command can use
the value you provide here, rather than requiring that you type the write community string
each time you invoke the command.
Tip: If no value is provided here, the default settings are used (see "Configure Default
Community Strings (SNMPv1 or SNMPv2c)" (on page 73)).
Configure SNMPv3 Settings for Regions
NNMi can use SNMPv3 user-based security model (USM) settings to access devices.
To view the current list of SNMPv3 USM settings for a Region:
1. Navigate to the SNMPv3 Settings tab on the Communication Region form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
c. Navigate to the Regions tab.
d. Do one of the following:
o To create a region definition, click the
New icon.
o To edit a region definition, select a row, click the
Open icon.
e. In the Communication Region form, access the SNMPv3 Settings tab.
2. The displayed table lists the Unique Name of each SNMPv3 USM setting for this region.
Page 92 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Note: NNMi tries to use the Specific Node SNMPv3 Settings. If none match, NNMi tries the Region
SNMPv3 Settings provided here. If none match, NNMi tries the default SMNPv3 settings.
3. You can also do the following:
n
To establish a new setting, click the
form" (on page 93).
Save and Close to return to the Communication Region form.
Click
n
To edit an existing setting, select a row, click the
SNMPv3 Settings form" (on page 93).
Click
n
New icon. See "Communication Region SNMPv3 Settings
Open icon. See "Communication Region
Save and Close to return to the Communication Region form.
To delete a setting from the Region's list, select a row and click the
Delete icon.
Note:The record remains in the database for possible use elsewhere and is simply removed from
this Communication Region's list.
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Communication Region SNMPv3 Settings form
NNMi can use SNMPv3 user-based security model (USM) settings to access devices.
NNMi tries to use the current SNMPv3 Settings attribute value from Specific Node Settings. If none match,
NNMi tries the Region SNMPv3 Settings provided here. If none match, NNMi tries the default SMNPv3
settings.
To configure an SNMPv3 Setting for a Region:
1. Navigate to the Communication Region SNMPv3 Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
c. Navigate to the Regions tab.
d. Do one of the following:
o To create a region definition, click the
New icon.
o To edit a region definition, select a row, click the
Open icon.
e. In the Communication Region form, navigate to the SNMPv3 Settings tab.
f. Do one of the following:
o To create an SNMPv3 Setting definition, click the
o To edit an SNMPv3 Setting, select a row, click the
New icon.
Open icon.
o To remove an SNMPv3 Setting from this Region, select a row, click the
Delete icon.
Note: The record remains in the database for possible use elsewhere and is simply
removed from this Communication Region's list.
2. Click the SNMPv3 Settings
Page 93 of 1087
Lookup icon and select one of the options from the drop-down
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
menu:
n
Quick View to display summary information for the currently configured (selected) SNMPv3
Setting name.
n
Quick Find to view and select from the list of all existing SNMPv3 Settings (for more
information see "Use the Quick Find Window" (on page 28)).
n
Open to display the details of the currently configured (selected) SNMPv3 Setting (see
"SNMPv3 Settings Form" for more information).
n
New to create a new SNMPv3 Setting (see "SNMPv3 Settings Form" for more information).
3. Click
Save and Close to return to the Communication Region SNMPv3 Settings form.
4. Click
Save and Close to return to the Communication Region form.
5. Click
Save and Close to return to the Communication Configuration form.
6. Click
Save and Close to apply your changes.
Configure Credential Settings for Regions (NNM iSPI NET)
The HP Network Node Manager iSPI Network Engineering Toolset Software uses Default Credential
Settings to access devices when running Diagnostics either automatically or when the Actions → Run
Diagnostics option is used. (See "Configure Diagnostics for an Incident (NNM iSPI NET)" (on page 417)
and Node Form: Diagnostics Tab for more information.)
NNM iSPI NET uses Secure Shell (SSH) to establish a secure connection with devices in your network
environment, using the credentials provided here. If the SSH attempt fails, NNMi uses Telnet protocol as
the communication method.
To provide credential settings for this region:
1. Navigate to the Region Device Credentials form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Regions tab.
d. Do one of the following:
o To establish a region definition, click the
New icon, and continue.
o To edit a region definition, select a row, click the
Open icon, and continue.
e. In the Communication Region form, navigate to the Device Credentials tab.
f. Do one of the following:
o To establish a credential setting, click the
New icon, and continue.
o To edit a credential setting, select a row, click the
Open icon, and continue.
o To delete a credential setting, select a row and click the
Delete icon
2. Provide the attribute values of credentials for this region (see table).
Page 94 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Note: NNMi tries to use the Specific Node Device Credentials. If none match, NNMi tries the Region
Device Credential settings provided here. If none match, NNMi tries the Default Device
Credentials.
3. Click
Save and Close to return to the Communication Region form.
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Device Credential Attributes for this Region
Attribute
Description
User
Name
Type the user name that you want NNMi to use for logging into devices in this
Communication Region.
Password
Type the password that you want NNMi to use for logging into devices in this
Communication Region.
Note: NNMi encrypts the password and displays asterisks for this attribute. If you want to
change the password, first clear the asterisks displayed in the Password attribute and
enter the new Password value.
Configure Specific Nodes (Communication Settings)
Configuring communication protocols for specific devices is optional.
Use the Specific Node Settings tab to fine tune communication protocol usage and settings for a particular
device within your environment. For example, provide settings for your most important devices, or disable
communication with the least important devices.
When you leave a field blank, NNMi uses the next applicable configuration setting for that field in the
following order:
l
The value configured for a Region that includes this device. If multiple Region definitions include this
device (for example, buildings, floors within those buildings, or workgroups within a particular floor),
the first match applies (the matching region with the lowest Ordering number) . See "Configure
Regions (Communication Settings)" (on page 79).
l
The default value for this field (see "Configure Default SNMP and ICMP Protocol Settings" (on page
67), "Configure Default Community Strings (SNMPv1 or SNMPv2c)" (on page 73), "Configure the
Default Device Credentials (NNM iSPI NET)" (on page 78), and "Configure Default SNMPv3 Settings"
(on page 76).
Note: NNMi enables you to set up one or more SNMP Proxy Servers in the cases where an SNMP node is
otherwise unreachable (for example, when a node you want to manage is behind a firewall). To
enable NNMi to use the SNMP Proxy Server, when you configure communication protocols for
specific devices, you must include the IP address and port number on the SNMP Proxy Server. See
"Specific Node Settings Form (Communication Settings)" (on page 96) for more information.
To configure specific devices, you have two choices:
l
"Specific Node Settings Form (Communication Settings)" (on page 96).
l
"Load Specific Node Settings from a File" (on page 106)
Page 95 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Specific Node Settings Form (Communication Settings)
Create specific node settings to control the way NNMi monitors your most important devices or least
important devices.
Tip: If no value is provided for an attribute in the Communication Node form, NNMi uses the applicable
Region settings and if none match, NNMi uses the default settings.
If configuring Specific Node Settings, see the HP Network Node Manager i Software Deployment
Reference for additional considerations: http://h20230.www2.hp.com/selfsolve/manuals.
To configure communication protocol settings for a specific node:
1. Access the Specific Node Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Communication Configuration.
c. Navigate to the Specific Node Settings tab.
d. Do one of the following:
o To establish settings for a node, click the
New icon, and continue.
o To edit settings for a node, select a row, click the
Open icons, and continue.
o To delete settings for a node, select a row and click the
Delete icon.
2. Provide the communication protocol settings for the node (see the Basic Settings table, SNMP
Settings table, and ICMP Settings table).
For an explanation of how NNMi implements timeout and retry configurations, see "Timeout / Retry
Behavior Example for SNMP" (on page 72) and "Timeout / Retry Behavior Example for ICMP" (on
page 73).
3. Optional. Make additional configuration choices. Click here for a list of choices .
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Basic Settings for this Device
Attribute
Description
Target
Hostname
The case-sensitive Hostname attribute value from the Node form of the discovered node
must match what is entered here.
NNMi follows a set of rules to dynamically generate the value stored in the NNMi
database for each Node's Hostname. Click here for details.
Note: The actual Hostname might be converted to all uppercase or all lowercase before it
is added to the NNMi database (depending on how the NNMi administrator
configured settings in the nms-topology.properties file). See the information
about the nms-topology.properties file in the HP Network Node Manager i
Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals.
l
If the Node supports SNMP, NNMi requests the Hostname using the IP Address of the
associated SNMP agent (the Management Address attribute value on the Node form).
Page 96 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
If the NNMi administrator chooses
Communication Configuration:
n
If the SNMP Agent does not respond, NNMi checks for another Management
Address to request the Hostname, and the Hostname could change.
n
If the SNMP Agent associated with the node changes, the Management Address
and Hostname could change.
If the NNMi administrator disables
Communication Configuration:
l
Enable SNMP Address Rediscovery in the
Enable SNMP Address Rediscovery in the
n
If the SNMP Agent does not respond, NNMi uses the previously gathered
Management Address attribute value to request the Hostname.
n
If the SNMP Agent associated with the node changes, NNMi uses the previously
gathered Management Address attribute value to request the Hostname.
If the Node does not support SNMP, no Management Address is available. NNMi
requests a Hostname starting with the lowest IP Address associated with the node (a
Discovery Seed value or an IP address value gathered from a neighboring device).
NNMi uses the first Hostname provided. The Hostname might change during a future
discovery cycle.
Preferred
Do one of the following:
Management
l Specify the address you want NNMi to use for SNMP communications with this
Address
device. If you enter an invalid or unreachable address, the device is not discovered or
monitored.
l
Leave this attribute empty. NNMi dynamically selects the management address,
based on responses from the device's SNMP agent.
Note: The NNMi administrator can over-ride this setting. See the Enable SNMP
Communication attribute and the Enable SNMP Address Rediscovery attribute
settings.
SNMP Settings for this Device
Attribute
Description
Enable SNMP
Communication
If enabled, the Discovery Process and State Poller Service generate network traffic
with SNMP protocol to discover and monitor this device.
Page 97 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Note: Your choice might be overridden if Monitoring Configuration settings disable
SNMP usage for the State Poller Service, see "Set Global Monitoring" (on page
215) or "Configure Monitoring Behavior" (on page 214).
If
disabled, NNMi does not generate any SNMP traffic to this device.
Caution: With no SNMP data, Spiral Discovery interprets each IP Address as a
separate node, Causal Engine calculates Status based only on IP address
State, previously discovered Interfaces show a State attribute value of "Not
Polled" and a Status attribute value of "No Status" with the Interface mapsymbol color set to beige, and no new Interfaces are discovered.
Page 98 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Enable SNMP
Address
Rediscovery
Note: The NNMi administrator can over-ride this setting. See the Enable SNMP
Communication and the Preferred Management Address attributes.
If enabled, NNMi automatically identifies which management address (SNMP
agent) to use for each device. If the initially configured address becomes unreachable,
NNMi automatically locates another SNMP agent, if possible, and changes the
management address attribute value. Click here for more information.
When NNMi first discovers a node, the seed address (provided by the NNMi
administrator) or discovered address (for non-seeded nodes) becomes the initial
Management Address of the node. After NNMi builds an inventory of all IP addresses
associated with the node (see "How Spiral Discovery Works" (on page 113)), NNMi
follows a set of rules to determine which address is the best choice for each node's
Management Address:
Note: With NNMi Advanced, the NNMi administrator specifies whether NNMi prefers
IPv4 or IPv6 addresses when selecting the Management Address. See the HP
Network Node Manager i Software Deployment Reference, which is available
at: http://h20230.www2.hp.com/selfsolve/manuals
1. NNMi ignores the following addresses when determining which Management
Address is most appropriate:
n
Any address of an administratively-down interface.
n
Any address that is virtual (HSRP/VRRP).
n
Any IPv4 Anycast Rendezvous Point IP Address 1 or IPv6 Anycast address.
n
n
Any address in the reserved loopback network range. IPv4 uses 127/24
(127.*.*.*) and IPv6 uses ::1.
Any IPv6 link-local address 2.
2. NNMi prefers loopback interfaces for management communication.
n
n
If a node has only one loopback address 3, and the associated SNMP agent
responds to NNMi, that address becomes the Management Address.
If a node supports multiple loopback addresses, NNMi queries each
loopback addresses, starting with the lowest number. NNMi uses the
loopback address with the lowest number from which the SNMP agent
responds (for example, 10.16.42.197 is a lower number than 10.16.197.42).
3. If no loopback address responds, NNMi queries the last-known Management
Address (if any).
1Rendezvous Point addresses are loopback addresses used for routers in multi-cast network
configurations.
2A non-routable IPv6 unicast address only used for communication with other nodes on the same link
(LAN or VLAN). Link local addresses cannot be used for communication that must be forwarded through a
router. IPv6 auto-configuration automatically assigns a unique link local address in the fe80::/10 address
space to each IPv6-enabled interface on a system.
3The address associated with the loopback interface. The loopback interface is a virtual interface on a
device that provides a route for internal communication. Many vendors provide a specially configured
loopback for management purposes. Exact details of how loopbacks are configured varies by vendor and
model. See each device's documentation for details. NNMi identifies these loopback addresses by using
IfType 24, softwareloopback from the IANA ifType-MIB.
Page 99 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
4. If no response, NNMi queries up to 10 of any remaining IP addresses in the
node's IP address inventory, starting with the lowest number. NNMi uses the
address with the lowest number from which the SNMP agent responds.
5. If no response, NNMi might be configured to repeat the sequence using
SNMPv1, SNMPv2c, or SNMPv3 in the order specified by the NNMi administrator
(Communication Configurations SNMP Minimum Security Level settings).
6. When all else fails, NNMi retains the last known Management Address (if any)
and automatically changes the State of that SNMP Agent object to Critical.
This process is repeated during each Auto-Discovery cycle, and the Management
Address can change. For example, NNMi's inventory of addresses for the node
expands, or the current Management Address does not respond to SNMP queries due
to network problems or node reconfiguration. The NNMi administrator can prevent
changes to the management address using the Communication Configurations
Enable SNMP Address Rediscovery or Preferred Management Address setting.
If disabled, when the current management address (SNMP agent) becomes
unreachable, NNMi reclassifies the node as a non-SNMP node until the previously
configured management address is available again.
Page 100 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Enable SNMP
GetBulk
Applies only to SNMPv2 or higher. Some devices do not respond well to multiple
SNMP OIDs requests at one time. If you have devices in your network environment that
have trouble responding to GetBulk commands, you can instruct NNMi to use Get or
GetNext instead of GetBulk.
If enabled, NNMi uses the SNMPv2 GetBulk command to gather information from
this device.
If disabled, NNMi uses the SNMP Get or GetNext command to gather information
from this device (requesting responses for one SNMP OID at a time).
SNMP Timeout
(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999
milliseconds.
Time that NNMi waits for a response to an SNMP query before reissuing the request.
Both the Discovery Process and the State Poller Service use this setting for this device.
For an explanation of how NNMi implements timeout and retry configurations, see
"Timeout / Retry Behavior Example for SNMP" (on page 72).
SNMP Retries
Count
Maximum number of retries that NNMi issues for an SNMP query before determining
the query result to be "unresponsive". Zero means no retries. Both the Discovery
Process and the State Poller Service use this setting for this device.
SNMP Port
Default is 161. Specifies the management server's port that NNMi uses when
generating SNMP traffic. Both the Discovery Process and the State Poller Service use
this setting for this device.
SNMP Proxy
Address
Optional. IP address of the your SNMP Proxy Server (for example, a proxy that gathers
data from non-SNMP devices and can use that data to respond to NNMi SNMP
requests).
To enable a proxy, you must also provide the port number of your SNMP Proxy Server.
See SNMP Proxy Port (next attribute).
SNMP Proxy
Port
Optional. Port number of the your SNMP Proxy Server.
To enable a proxy, you must also provide the IP address of your SNMP Proxy Server.
See SNMP Proxy Address (previous attribute).
Note: The SNMP Minimum Security Level is determined by the settings on the Communication
Configurations' Specific Node Settings form, SNMPv3 Settings tab where SNMPv3 Settings for this
Node are established.
ICMP Settings for this Device
Attribute
Description
Enable ICMP
Communication
If
enabled, NNMi generates network traffic with ICMP protocol to this device.
If
disabled, NNMi does not generate any ICMP traffic to this device:
Page 101 of 1087
l
Addresses in this Node (both previously discovered and newly discovered) have a
State attribute value of "Not Polled" and a Status attribute value of "No Status" with
the IP Address map-symbol color set to beige.
l
If both ICMP and SNMP are disabled, the Node has a Status attribute value of "No
Status" have a map-symbol background shape color set to beige.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
Note: Your choice might be overridden if Monitoring Configuration settings disable
ICMP usage for the State Poller Service, see "Set Global Monitoring" (on page
215) or "Configure Monitoring Behavior" (on page 214).
ICMP Timeout
(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999
milliseconds.
Time that NNMi waits for a response to an ICMP query before reissuing the request to
this device. For an explanation of how NNMi implements timeout and retry
configurations, see "Timeout / Retry Behavior Example for ICMP" (on page 73).
ICMP Retries
Count
Maximum number of retries that NNMi issues for an ICMP query to this device before
logging an error. Zero means no retries.
Related Topics:
"Configure Default SNMP and ICMP Protocol Settings" (on page 67)
"Configure Default Community Strings (SNMPv1 or SNMPv2c)" (on page 73)
"Configure Regions (Communication Settings)" (on page 79)
Configure SNMPv1/v2 Community Strings for a Specific Node
Optional. Configure the SNMPv1 or SNMPv2c community strings for each node.
NNMi uses the SNMPv2 settings to discover the SNMPv2 information about your network. This also
determines whether NNMi receives or discards incoming SNMPv2 traps. Click here for more information.
l
If the incoming trap's Source Node object or Source Object (such as card or interface) has not yet been
discovered by NNMi, see "Handle Unresolved Incoming Traps" (on page 428) for additional
information. See also "Configure Network Devices to Send SNMP Notifications to NNMi" (on page
424).
l
If the Source Node or Source Object of the incoming trap has been discovered by NNMi using
SNMPv2c or SNMPv1, NNMi accepts incoming traps from SNMPv2c or SNMPv1, but NNMi discards
incoming traps from SNMPv3.
l
NNMi discards traps that have no Incident Configuration or with an Incident Configuration set to
Disabled.
l
If either the Source Node or Source Object has Management Mode set to Not Managed or Out of
Service in the NNMi database, NNMi always discards the incoming trap. See "Understand the Effects
of Setting the Management Mode to Not Managed or Out of Service " (on page 255).
NNMi provides the Management Mode workspace so that you can quickly view lists of all nodes,
interfaces, cards, addresses, or node components that NNMi is not currently discovering or monitoring.
For information about these views:
Note: If you want the NNMi management server to forward SNMPv2 traps to other machines in your
network environment, see "Configuring Trap Forwarding" (on page 295) for additional configuration
steps.
To provide SNMPv1/v2 community strings for a specific device:
Page 102 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
1. Navigate to the Specific Node Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Specific Node Settings tab.
d. Do one of the following:
o To establish a node definition, click the
New icon, and continue.
o To edit a node definition, select a row, click the
Open icon, and continue.
2. Navigate to the SNMPv1/v2 Community Strings tab.
3. To provide a read community string, navigate to the Read Community String attribute and provide
the appropriate string (see table).
Tip: If you do not provide any read community string, NNMi uses the applicable Region settings and if
none match, NNMi uses the default settings .
4. To provide a write community string, navigate to the Write Community String attribute and provide
the appropriate string (see table).
Tip: If you do not provide any write community string, NNMi uses the applicable Region setting and if
none match, NNMi uses the default setting .
5. Click
Save and Close to return to the Communication Configuration form.
6. Click
Save and Close to apply your changes.
SNMPv1 or SNMPv2c Community String for this Device
Attribute
Description
Read
Community
String
The SNMPv1 or SNMPv2c "get" (read-only) community string that is used for this device
(case-sensitive).
Tip: If you do not provide any read community string, NNMi uses the applicable Region
settings and if none match, NNMi uses the default settings .
Many proxy vendors use the read community string for specifying remote target
information. NNMi supports substitution parameters within read community strings for
SNMPv1 or SNMPv2 proxy environments. Click here for more information.
Copy and paste these codes at the end of your read community string to provide the values
required by your proxy environment. NNMi substitutes the actual attribute values from the
NNMi database at runtime:
${contextName} = Used for specifying VLAN context for switches (VLAN associated with
the remote target node)
${managementAddress} = Node form, Management Address attribute value (the remote
target node)
${snmpPort} = SNMP Agent form, UDP Port attribute value (SNMP agent associated with
the remote target node)
Write
Community
String
The SNMPv1 or SNMPv2c "set" (write) community string that is used for this device (casesensitive).
Optional. For use with the nnmsnmpset.ovpl command line tool.
Page 103 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Attribute
Description
SNMPv1 and SNMPv2c require that you know the SNMP agent's write community string
before you can change settings on any device. The nnmsnmpset.ovpl command can use
the value you provide here, rather than requiring that you type the write community string
each time you invoke the command.
Tip: If you do not provide any write community string, NNMi uses the applicable Region
setting and if none match, NNMi uses the default setting.
Configure SNMPv3 Settings for a Specific Node
NNMi can use SNMPv3 user-based security model (USM) settings to access devices.
NNMi uses the current SNMPv3 Settings provided a node, if available.
To configure an SNMPv3 Settings for a specific node:
1. Navigate to the Specific Node Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Specific Node Settings tab.
d. Do one of the following:
o To establish a node definition, click the
New icon, and continue.
o To edit a node definition, select a row, click the
Open icon, and continue.
2. Navigate to the SNMPv3 Settings tab.
3. Click the SNMPv3 Settings
menu:
Lookup icon and select one of the options from the drop-down
n
Quick View to display summary information for the currently configured (selected) SNMPv3
Setting name.
n
Quick Find to view and select from the list of all existing SNMPv3 Settings (for more
information see "Use the Quick Find Window" (on page 28)).
n
Open to display the details of the currently configured (selected) SNMPv3 Setting (see
"SNMPv3 Settings Form" for more information).
n
New to create a new SNMPv3 Setting (see "SNMPv3 Settings Form" for more information).
4. Click
Save and Close to return to the Specific Node Settings form.
5. Click
Save and Close to return to the Communication Configuration form.
6. Click
Save and Close to apply your changes.
Configure Credential Settings for a Specific Node (NNM iSPI NET)
HP Network Node Manager iSPI Network Engineering Toolset Software uses Default Credential Settings
to access devices when running Diagnostics either automatically or when the Actions → Run Diagnostics
Page 104 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
(iSPI NET only) option is used. (See "Configure Diagnostics for an Incident (NNM iSPI NET)" (on page
417) and Node Form: Diagnostics Tab for more information.)
NNM iSPI NET uses Secure Shell (SSH) to establish a secure connection with devices in your network
environment, using the credentials provided here. If the SSH attempt fails, NNMi uses Telnet protocol as
the communication method.
To provide credential settings for a specific node:
1. Navigate to the Specific Node Device Credentials form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Navigate to the Specific Node Settings tab.
d. Do one of the following:
o To establish a definition, click the
o To edit a definition, click the
New icon, and continue.
Open icon in the row representing the configuration you
want to edit, and continue.
e. In the Specific Nodes Settings form, navigate to the Device Credentials tab.
f. Do one of the following:
o To establish a credential setting, click the
New icon, and continue.
o To edit a credential setting, click the
Open icon in the row representing the
configuration you want to edit, and continue.
o To delete a credential setting, select a row and click the
Delete icon
2. Provide the attribute values of credentials for this node (see table).
Note: NNMi tries to use the Specific Node Device Credentials provided here. If none match, NNMi
tries the Region Device Credential settings. If none match, NNMi tries the Default Device
Credentials.
3. Click
Save and Close to return to the Specific Node Settings form.
4. Click
Save and Close to return to the Communication Configuration form.
5. Click
Save and Close to apply your changes.
Specific Node Device Credential Attributes
Attribute
Description
User
Name
Type the user name that you want NNMi to use for logging into this device.
Password
Type the password that you want NNMi to use for logging into this device.
Note: NNMi encrypts the password and displays asterisks for this attribute. If you want to
change the password, first clear the asterisks displayed in the Password attribute and
enter the new Password value.
Page 105 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Load Specific Node Settings from a File
Import a list of devices, using a command line command. You also have the option of importing the
SNMPv1 or SNMPv2c community strings (read and write) or the SNMPv3 USM settings for each device.
This is useful when your SNMP is managed by a change control mechanism. You can bulk insert the
SNMP assignments into NNMi. Each assignment shows up as an individual entry in the table on the
Communication Configuration form's Specific Node Settings tab.
If configuring Specific Node Settings, see the HP Network Node Manager i Software Deployment
Reference for additional considerations: http://h20230.www2.hp.com/selfsolve/manuals.
To import SNMP assignments:
1. On the NNMi management server's hard drive, create a text file according to the specifications in the
nnmcommload.ovpl reference page. Create one line for each device. For more information, see
nnmcommload.ovpl
To add comments to your file, place a # character at the beginning of each comment line.
Note: When you load this file, the data in the file overwrites any previously entered information about
each Hostname (case-sensitive).
2. Use the following command line command to load the information into the NNMi database:
If you do not want to enter an NNMi User Name attribute value and an NNMi Password attribute
value at the command line, you can use the nnmsetcmduserpw.ovpl command to specify the valid
user name and password (instead of -u and -p). The credentials set using the
nnmsetcmduserpw.ovpl command are valid for command execution by the same user. See "Set Up
Command Line Access" (on page 273) for more information.
Windows:
%NnmInstallDir%\bin\nnmcommload.ovpl -u <NNMiadminUserName> -p
<NNMiadminPassword> -file <path/filename>
UNIX:
/opt/OV/bin/nnmcommload.ovpl -u <NNMiadminUserName> -p <NNMiadminPassword> file <path/filename>
3. Verify that the import worked properly:
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Communication Configuration.
c. Access the Specific Node Settings tab.
4. Review each entry in the table to verify that the import was successful.
To verify the SNMP configuration for an IP Address, at the command line, type:
Note: For more information, see nnmcommconf.ovpl
If you do not want to enter an NNMi User Name attribute value and an NNMi Password attribute value at
the command line, you can use the nnmsetcmduserpw.ovpl command to specify the valid user name and
password (instead of -u and -p). The credentials set using the nnmsetcmduserpw.ovpl command are
valid for command execution by the same user. See "Set Up Command Line Access" (on page 273) for
more information.
Page 106 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Windows:
%NnmInstallDir%\bin\nnmcommconf.ovpl -u <NNMiadminUsername> -p <NNMiadminPassword>
-proto snmp -host <node IP address>
UNIX:
/opt/OV/bin/nnmcommconf.ovpl -u <NNMiadminUsername> -p <NNMiadminPassword> -proto
snmp -host <node IP address>
To verify the ICMP configuration for an IP Address, at the command line, type:
Note: For more information, see nnmcommconf.ovpl
If you do not want to enter an NNMi User Name attribute value and an NNMi Password attribute value at
the command line, you can use the nnmsetcmduserpw.ovpl command to specify the valid user name and
password (instead of -u and -p). The credentials set using the nnmsetcmduserpw.ovpl command are
valid for command execution by the same user. See "Set Up Command Line Access" (on page 273) for
more information.
Windows:
%NnmInstallDir%\bin\nnmcommconf.ovpl -u <NNMiadminUsername> -p <NNMiadminPassword>
-proto icmp -host <node IP address>
UNIX:
/opt/OV/bin/nnmcommconf.ovpl -u <NNMiadminUsername> -p <NNMiadminPassword> -proto
icmp -host <node IP address>
Troubleshooting Communication Settings
After you configure your communication settings and wait until Auto-Discovery completes at least one
cycle, you can verify your Communication Settings:
l
"Verify That All Nodes Support SNMP" (on page 108)
l
"Verify a Node's Communication Settings" (on page 108)
l
"Identify Unexpected Overrides of Communication Settings" (on page 109)
l
"Resolve Authentication Errors" (on page 110)
You can fine tune NNMi's SNMP/ICMP traffic in the following ways:
l
Minimize timeouts and retries.
When NNMi attempts to contact a node using ICMP / SNMP during an Auto-Discovery cycle, the
Communication Configuration settings determine what information NNMi can gather. If the correct
ICMP / SNMP settings are not provided or if NNMi discovers non-SNMP devices (see "Verify That All
Nodes Support SNMP" (on page 108)), NNMi resorts to timeouts and retries.
Large timeout values or a high number of retries can degrade overall performance of discovery. If your
network environment contains nodes that you know respond slowly to ICMP / SNMP requests, consider
using the Regions or Specific Nodes settings to fine tune the number of timeouts and retries NNMi
uses during each Auto-Discovery cycle.
l
Limit the number of default SNMPv1/SNMPv2c Community Strings to ensure efficient Auto-Discovery
performance. See "Configure Default Community Strings (SNMPv1 or SNMPv2c)" (on page 73).
l
Limit the number of default SNMPv3 user-based security model (USM) settings to ensure efficient AutoDiscovery performance. See "Configure Default SNMPv3 Settings" (on page 76).
Page 107 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Verify That All Nodes Support SNMP
After you configure your communication settings and wait until Auto-Discovery completes at least one
cycle, check for any nodes that do not respond to SNMP:
1. From the workspace navigation panel, select the Inventory workspace.
2. Select the Nodes view.
3. Right-click the Device Profile column, and select Create Filter.
4. Select "contains", and type the following text into Enter a string: No SNMP.
5. NNMi displays a list of all nodes in your network environment that did not respond to SNMP during
Auto-Discovery.
6. Verify that the resulting list is valid.
7. To troubleshoot unexpected results, see:
n
"Verify a Node's Communication Settings" (on page 108)
n
"Identify Unexpected Overrides of Communication Settings" (on page 109)
n
"Resolve Authentication Errors" (on page 110)
Verify a Node's Communication Settings
After you configure your communication settings and wait until Auto-Discovery completes at least one
cycle, you can check to determine what settings NNMi is using to communicate with a node of interest.
NNMi provides a report about the communication configuration information for a selected node, including
the SNMP and ICMP configuration information.
To display a report of a node's current communication settings:
Note: You must have Administrator role to use this action.
1. Do one of the following:
Navigate to a table view and select a node:
a. From the workspace navigation panel, select the workspace of interest. For example,
Inventory.
b. Select the view that contains the node with communication settings you want to check. For
example, Nodes.
c. From the table view, select the
settings you want to check.
check box that precedes the node with communication
Navigate to a map view and select a node:
a. From the workspace navigation panel, select the workspace of interest; for example,
Topology Maps.
b. Click the view that contains the node with communication settings you want to check; for
example Network Overview.
c. From the map view, click the node with communication settings you want to check.
Page 108 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Navigate to a Node form:
n
From a table view, click the
n
From a map view, click the node of interest on the map and click the
Open icon that precedes the node of interest.
Open icon.
2. Select Actions → Communication Settings.
Sometimes a device is temporarily not responding properly to SNMP during NNMi's initial discovery, so
NNMi makes the wrong decision about which version of SNMP to use. Or perhaps you deployed upgrades
to the SNMP agents in your network environment.
To update NNMi's choice of SNMP version used for a Node or Nodes:
Note: You must have Administrator role to use this action.
1. From the workspace navigation panel, select Inventory.
2. Select the Custom Nodes view.
3. Click the Protocol Version column heading to sort the view according to SNMP version currently
being used by NNMi for communications with each SNMP agent in your network environment.
4. Select all rows that you want NNMi to check for SNMP upgrades or changes.
5. select Actions → Configuration Poll.
NNMi reconfigures the SNMP Communication settings by verifying the highest SNMP version
available to the SNMP Agent assigned to the node (according to your Communication Configuration
settings).
6. Click the Protocol Version column heading to resort the view according to SNMP version.
7. Verify that NNMi made the expected changes.
If still receiving unexpected results, see "Identify Unexpected Overrides of Communication Settings"
(on page 109).
See "Configuring Communication Protocol" (on page 66) for information about configuring communication
settings.
Related Topics
nnmcommconf.ovpl
Identify Unexpected Overrides of Communication Settings
Even if the communication settings enable ICMP / SNMP protocol traffic to an area of your network (see
"Configuring Communication Protocol" (on page 66)), that type of traffic might be disabled in the
monitoring settings (see "Monitoring Network Health" (on page 213)).
To determine whether your Communication Configuration settings are being overridden:
Note: You must have Administrator role to use this action.
1. Do one of the following:
Navigate to a table view and select a node:
a. From the workspace navigation panel, select the workspace of interest. For example,
Page 109 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
Inventory.
b. Select the view that contains the node with communication settings you want to check. For
example, Nodes.
c. From the table view, select the
settings you want to check.
check box that precedes the node with communication
Navigate to a map view and select a node:
a. From the workspace navigation panel, select the workspace of interest; for example,
Topology Maps.
b. Click the view that contains the node with communication settings you want to check; for
example Network Overview.
c. From the map view, click the node with communication settings you want to check.
Navigate to a Node form:
n
From a table view, click the
n
From a map view, click the node of interest on the map and click the
Open icon that precedes the node of interest.
Open icon.
2. Select Actions → Monitoring Settings.
NNMi displays a report showing ICMP and SNMP communication configuration settings for this node.
Tip: If either the Monitoring settings or the Communication settings disable ICMP or SNMP traffic to a
node, NNMi does not use that protocol for communication with that node. See also "Verify a
Node's Communication Settings" (on page 108).
(NNMi Advanced) If the Global Network Management feature is enabled and you are signed into a
Global Manager:
n
Node managed by the Global Manager = Actions → Monitoring Settings displays a report,
provided by the Global Manager (NNMi management server).
n
Node managed by a Regional Manager = Actions → Monitoring Settings accesses that Regional
Manager (NNMi management server) and requests the report.
Note: You must sign into that Regional Manager unless your network environment enables
Single Sign-On (SSO) to that Regional Manager through the Global Manager.
Resolve Authentication Errors
To create a list of authentication errors:
1. From the workspace navigation panel, select the Incident Browsing workspace.
2. Select an Incident view.
3. Right-click the Category column, and select Create Filter.
4. Select "equals", and select
Security.
5. NNMi displays a list of all incidents related to authentication errors; for example an SNMP
authentication failure (see also Node Down).
If NNMi generates incidents related to authentication failure during discovery, there are several
configuration settings that influence authentication errors:
Page 110 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Communication Protocol
l
Communication Configuration.
Each Node’s Management Address is the address NNMi uses to communicate with the Node’s SNMP
agent. The NNMi administrator can control NNMi behavior:
n
Specify the Management Address for a node (in the Communications Configuration, Specific
Nodes settings).
n
Otherwise, let NNMi choose an address from all IP addresses associated with each node. This
NNMi behavior can be fine-tuned by the NNMi administrator in the Discovery configuration settings.
Consider configuring smaller Regions with more focused lists of possible access credentials. Or
configure Specific Nodes to avoid requiring NNMi to try multiple possible settings.
l
Discovery Configuration.
The following Discovery Configuration fields influence NNMi’s use of SNMP (see "Configure Basic
Settings for the Auto-Discovery Rule" (on page 141)):
n
Discovery Any SNMP Device field.
If disabled, NNMi discovers only Routers and Switches that respond to SNMP.
If enabled, NNMi discovers all devices that respond to SNMP.
n
Non-SNMP Devices field.
If disabled, when there is no SNMP response from the device, NNMi does not discover information
about the device or add a record of that device to the NNMi database.
If enabled, NNMi discovers devices that do not respond to SNMP and assigns the Device Profile
named No SNMP as the basis of the database record.
NNMi's access to SNMP agents is also influenced by the set of rules for choosing management
addresses and settings to exclude certain addresses.
l
Device Profiles.
The Device Profiles' Force Device attribute setting influences NNMi’s use of SNMP (see Device Profile
form).
l
Monitoring Configuration.
NNMi discovers and monitors devices in an ongoing basis (see "Monitoring Network Health" (on page
213)). To control management address discovery after the first NNMi discovery cycle, use the Enable
SNMP Address Rediscovery field to control NNMi behavior when previously discovered SNMP
agents quit responding (for example, when you reconfigure the device’s SNMP agent):
n
If disabled, NNMi reports the device as Node Down and does not attempt to find another
Communication Configuration setting that works.
n
If enabled, NNMi retries any configured values in search of one that works.
Page 111 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Discovering Your Network
Configure NNMi to discover only the nodes that are important to you and your team.
Using a wide range of protocols and techniques, NNMi Spiral Discovery gathers a wealth of information
about your network inventory, ascertains the relationships between devices (such as subnets and VLANs),
and accurately maps out the connectivity between those devices. The NNMi Causal Engine determines
the current status of each device (plus each associated interface and address within that device) and
proactively notifies you when NNMi detects any trouble or potential trouble.
This dynamic discovery process continues over time. When things change in your network management
domain, Spiral Discovery automatically updates information according to a schedule that you set. The
topology maps always reflect accurate timely information about any changes in your network.
Note: Review and complete the prerequisites before configuring discovery, "Prerequisites for Discovery"
(on page 123).
You decide which nodes are discovered and how often NNMi checks for new devices in your network (see
"Determine Your Approach to Discovery" (on page 126) for ideas). The steps required depend on what you
want to do:
l
"Adjust the Rediscovery Interval" (on page 137) – Optional. The time NNMi waits between the
discovery cycles that keep your network information current. By default, NNMi updates information
about devices and connections every 24 hours.
l
"Configure the Node Name Strategy" (on page 138) – Optional. Choose the node naming strategy for
NNMi to use for the map icons and in the Name column of the table views.
l
"Configure Auto-Discovery Rules" (on page 139) – Optional. Specify whether you want NNMi to
automatically discover groups of network devices (identified by IP address ranges and MIB II
sysObjectIDs). NNMi extends discovery by using requests for Address Resolution Protocol (ARP)
cache information about neighbors. NNMi uses a variety of protocols to gather information from all
neighbor devices. See "Auto-Discovery Rules" (on page 119) for more details.
Specify whether NNMi uses Ping Sweep (ICMP ping) or your Discovery Seeds as starting points for
gathering information about neighboring devices. Note that with NNMi Advanced, Ping Sweep works
only with IPv4 addresses, not IPv6 addresses.
NNMi discovers any devices that comply with your rule configurations, and creates a record of each
device in the NNMi database. If the device supports SNMP, all addresses for that device are combined
into one Node object. If the device does not support SNMP, NNMi queries DNS to determines the
hostname. If this hostname matches another non-SNMP node, NNMi merges the information to create
only one node with multiple associated addresses.
l
"Configure an Excluded IP Addresses Filter" (on page 153) – Optional. Specify addresses that you do
not want NNMi to discover.
l
"Specify Discovery Seeds: Initial Routers or Specific Nodes to be Discovered" (on page 156) –
Optional. Use Discovery Seeds to accomplish either of the following purposes:
n
Limit Spiral Discovery to only the seeds that you specify.
n
Provide seeds as starting points for your Auto-Discovery Rules.
For details about how Spiral Discovery works:
For a list of the types of things NNMi can discover, see About Map Symbols.
Page 112 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
From the information collected, NNMi constructs a model of your network configuration in the database,
and displays this information in the map views. See View Maps of Network Connectivity for more
information about the available map views.
How Spiral Discovery Works
NNMi uses a variety of network protocols (read-only queries) within your defined network management
domain to gather information about each discovered device. You see the real-time accumulation of
information as it is collected, rather than waiting until NNMi discovers your entire network environment.
Spiral Discovery dynamically gathers two categories of information from each discovered node:
1. Information about the node — NNMi gathers detailed information about each device. You can review
this data on the device's Node form. Examples of configuration details include IP address, subnet
information, sysObjectID, number of interfaces, and version of SNMP supported.
2. Conectivity details — NNMi gathers information about how devices are connected to each other on
Layer 21 and Layer 32 of your network.
1Refers to the Data Link layer of the multilayered communication model, Open Systems Interconnection
(OSI). The Data Link layer moves data across the physical links in the network. The switches and bridges
are devices that redirect data messages at the layer 2 level, using the destination Media Access Control
(MAC) address to determine where to direct the message.
2Refers to the Network layer of the multilayered communication model, Open Systems Interconnection
(OSI). The Network layer is concerned with knowing the address of the neighboring nodes in the network,
selecting routes and quality of service, and recognizing and forwarding incoming messages to local host
domains. The router and switch-router are the devices that redirect data messages at the Layer 3 level.
Everything in a subnet is connected at the Layer 3 (IP) level.
Page 113 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Page 114 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Spiral Discovery checks for changes according to a schedule determined by the Rediscovery Interval.
NNMi administrators can set the schedule to meet any service-level agreement (SLA) commitments.
After NNMi completes initial discovery of your network, ongoing discovery takes over according to the
Rediscovery Interval:
l
If a new node is added to your defined network management domain, NNMi dynamically updates the
topology database and maps. The node form provides details of the new node's configuration. The
maps reflect the new connectivity information.
l
If configuration settings change on an existing node, NNMi dynamically updates the database and
maps to reflect the changes.
The only exception is when non-SNMP addresses that had the same DNS hostname are changed to
have separate DNS hostnames, NNMi must completely rediscover the non-SNMP nodes to correctly
update the database objects (node, interface, address, connection, and incidents). The NNMi
administrator must delete the old non-SNMP node object and force NNMi to rediscover the new node
configurations. See "Delete Nodes" (on page 170).
Tip: At any time, you can initiate an on-demand discovery poll to gather the most current information about
a previously discovered device. Select a node and click the Actions → Configuration Poll command,
or use the nnmconfigpoll.ovpl command.
A number of NNMi tools let NNMi administrators control how Spiral Discovery works.
For details about how Spiral Discovery works:
Rediscovery Intervals
Specify how often your entire network is checked for the latest information.
This interval controls how often NNMi generates network traffic to gather the following information:
l
Information about the nodes, addresses, and interfaces you configure for discovery.
l
Information about Level 2 connectivity between interfaces and VLANs in your network.
l
Information about Level 3 connectivity between addresses in your network.
Make sure the interval value provides plenty of time so Spiral Discovery cycles do not overlap. The larger
your network environment, the longer the time required to complete a Spiral Discovery cycle.
See "Adjust the Rediscovery Interval" (on page 137) to learn how to set the rediscovery interval.
For details about how Spiral Discovery works:
Discovery Node Name Choices
Control how the Name attribute on node forms is populated during discovery. This Name value is used to
identify the object in NNMi maps and table views. You specify a hierarchy for discovery to use. You
configure three levels in the hierarchy. See "Node Name Decision Tree" (on page 117).
You can designate any of the following for each level of the node Name decision hierarchy:
l
DNS Names. Discovery uses the results of hostname resolution.
NNMi follows a set of rules to dynamically generate the value stored in the NNMi database for each
Node's Hostname. Click here for details.
Note: The actual Hostname might be converted to all uppercase or all lowercase before it is added to
Page 115 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
the NNMi database (depending on how the NNMi administrator configured settings in the nmstopology.properties file). See the information about the nms-topology.properties file in
the HP Network Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals.
n
If the Node supports SNMP, NNMi requests the Hostname using the IP Address of the associated
SNMP agent (the Management Address attribute value on the Node form).
If the NNMi administrator chooses
Configuration:
Enable SNMP Address Rediscovery in the Communication
o If the SNMP Agent does not respond, NNMi checks for another Management Address to
request the Hostname, and the Hostname could change.
o If the SNMP Agent associated with the node changes, the Management Address and Hostname
could change.
If the NNMi administrator disables
Configuration:
Enable SNMP Address Rediscovery in the Communication
o If the SNMP Agent does not respond, NNMi uses the previously gathered Management
Address attribute value to request the Hostname.
o If the SNMP Agent associated with the node changes, NNMi uses the previously gathered
Management Address attribute value to request the Hostname.
n
l
If the Node does not support SNMP, no Management Address is available. NNMi requests a
Hostname starting with the lowest IP Address associated with the node (a Discovery Seed value or
an IP address value gathered from a neighboring device). NNMi uses the first Hostname provided.
The Hostname might change during a future discovery cycle.
MIB II sysName Values. Device administrators set the sysName. Discovery avoids populating the
NNMi database with multiple devices having the same manufacturer's default sysName. If a sysName
matches or starts with the manufacturer's default factory setting (case-sensitive), discovery ignores
sysName as a choice for the Name attribute of the node. NNMi ships with a Device Profile for each
device type. The Device Profile includes a record of the manufacturer's default sysName.
Caution: You can override this choice using the Device Profile's Advanced settings, Never Use
sysName attribute. See "Configure Device Profiles" (on page 134) for more information.
l
IP addresses. The addresses are gathered from discovery seed addresses that you provided, ping
sweep configurations, or neighbor addresses gathered using Auto-DiscoveryRules. Discovery avoids
potential confusion when a device has multiple IP addresses by following these rules:
n
If the device supports SNMP, the address of the responding SNMP agent is recorded (the
Management Address) and the other addresses are associated with the node. See "Specific Node
Settings Form (Communication Settings)" (on page 96) for more information about configuring the
management address.
n
If the device does not support SNMP, NNMi queries DNS to determine the hostname. If this
hostname matches another non-SNMP node, NNMi merges the information to create only one
node with multiple associated addresses.
See "Configure the Node Name Strategy" (on page 138) to learn how to configure the NNMi node name
strategy.
For details about how Spiral Discovery works:
Page 116 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Node Name Decision Tree
For each discovered address, NNMi gathers multiple attributes that are used to implement your Node
Name strategy. NNMi chooses the node Name based on the Management Address, System Name, and
Hostname collected during discovery. The following diagram shows how NNMi determines values for
these attributes.
For details about how Spiral Discovery works:
Page 117 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Discovery Seeds (as a starting point)
An optional discovery seed is a specific node that you want NNMi to discover. For example, a discovery
seed might be a core router in your management environment.
Each discovery seed is identified by hostname (not case-sensitive) or IP address. When you add an
optional discovery seed, NNMi immediately tries to discover that device (without waiting until the next
regularly scheduled discovery interval). If discovery is not successful, NNMi tries again 10 minutes later,
and continues trying. The time between each attempt is doubled until the time reaches 1 week or equals
your current discovery interval.
NNMi discovers seed addresses regardless of how you configure Auto-Discovery Rule definitions or the
Excluded IP Addresses filter.
Note: Nodes configured as discovery seeds are always discovered and added to the topology database. If
you change your mind and delete a discovery seed configuration, the node is not automatically
deleted from the topology database. See "Delete Nodes" (on page 170).
If you configure one or more Auto-Discovery Rules, note the following:
l
Discover Included Nodes is enabled for an Auto-Discovery Rule, NNMi uses each discovery
If
seed as a starting point to gather information about neighboring devices to expand discovery.
Note: You can use the Ping Sweep option in your Auto-Discovery Rules in addition to or instead of
Discovery Seeds. Note that with NNMi Advanced, Ping Sweep works only with IPv4 addresses,
not IPv6 addresses.
l
If
Discover Included Nodes is disabled for an Auto-Discovery Rule, no devices matching that rule's
criteria are discovered and added to the topology database unless:
n
The device's address is a discovery seed.
See "Specify Discovery Seeds: Initial Routers or Specific Nodes to be Discovered" (on page 156) to
learn how to establish discovery seeds.
n
The device's address is reported as a neighbor to another discovered address.
If you want to ensure that an address is never added to the NNMi database, use the "Configure an
Excluded IP Addresses Filter" (on page 153) or "Configure an Excluded Interfaces Filter" (on page
155) settings.
For details about how Spiral Discovery works:
Ping Sweep (as a starting point)
You have two choices for Auto-Discovery starting points. Use either or both to best advantage in your
network environment:
l
Discovery Seeds
You designate specific hostnames (not case-sensitive) or IP addresses where Auto-Discovery starts
gathering neighbor information.
l
Ping Sweep
NNMi issues ICMP pings to certain addresses gathered from neighbor information.
Note: NNMi Advanced- Ping Sweep works only with IPv4 addresses, not IPv6 addresses.
Page 118 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Ping Sweep sends ICMP ping commands to IP addresses in the ranges defined in your Auto-Discovery
rules. Ping Sweep enforces the following limits to the ICMP pings:
n
For each specific IP address range, NNMi issues pings across a maximum of the last two octets in
the IPv4 address range. This is equivalent to a /16 subnet
n
ICMP pings are limited to 500 at one time. This avoids flooding your network or tripping spam
detection tools.
Ping Sweep is useful in wide area networks such as ATM, Frame Relay, and Point-to-Point that do not
contain an Address Resolution Protocol (ARP) cache.
You configure the Ping Sweep feature at two levels:
l
"Configure Ping Sweep Global Settings" (on page 137)
l
"IP Address Ranges for Auto-Discovery" (on page 143) (Ping Sweep configuration for each rule)
For details about how Spiral Discovery works:
Auto-Discovery Rules
Auto-Discovery Rules control the extent of automatic discovery. You choose the starting points for
automatic discovery (either Discovery Seeds or Ping Sweep, or both).
l
l
If
Discover Included Nodes is disabled for a particular Auto-Discovery Rule, nodes that match the
Rule criteria are affected as follows:
n
IP Address ranges are not used for gathering neighbor information, see "Limit Sources of Neighbor
Information" (on page 132).
n
System Object ID ranges are excluded from discovery. For examples, see "Specific System Object
IDs Not Discovered" (on page 133) .
If
Discover Included Nodes is enabled for a particular Auto-Discovery Rule, a variety of protocols
are used to gather information about the neighbors adjacent to each discovered device. Spiral
Discovery then requests neighbor information from each new neighbor. This sequence continues until
the boundaries identified by your rule definition are reached.
See "Configure Auto-Discovery Rules" (on page 139) to learn how to establish the rules that control
automatic discovery.
When defining Auto-Discovery Rules, you must provide at least one Auto-Discovery Rule that includes an
IP address range to define the limits of your management domain. By default NNMi discovers routers and
switches. You can expand the number of device types that NNMi discovers by enabling Discover Any
SNMP Device and including one or more System Object ID Ranges (based on MIB II sysObjectID values).
Your address ranges and system object ID ranges determine which discovered addresses are added to
the NNMi database.
NNMi gathers information about neighboring devices using ARP cache, DNS, and the following protocols:
l
BGP — Border Gateway Protocol
l
CDP — Cisco Discovery Protocol
l
EIGRP — Cisco Enhanced Interior Gateway Routing Protocol
l
ENDP — Enterasys Discovery Protocol (also known as CDP - Cabletron Discovery Protocol)
Page 119 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
l
FDP — Foundry Discovery Protocol
l
OSPF — Open Shortest Path First
In Wide Area Networks (WANs) such as ATM, Frame Relay, and Point-to-Point (where ARP cache is not
available), the optional Ping Sweep (IPv4-only) feature locates nodes for Auto-Discovery to use when
gathering neighbor information and evaluating subnet connection rules (IPv4-only).
For details about how Spiral Discovery works:
Filters to Exclude Certain IP Addresses from Discovery
When configuring Spiral Discovery in NNMi, sometimes it is useful to exclude certain addresses or ranges
of addresses from discovery and monitoring. For example:
l
There are multiple Nortel switches in your environment. They each have a non-routable IP address of
192.168.168.168 that is defined by the manufacturer. This special address is used to establish the
default VLAN for the switch. However, NNMi discovers this duplicate address and establishes a lot of
unnecessary connections on the Layer 3 Neighbor View map.
l
Your service provider forbids the generation of ICMP or SNMP traffic from your NNMi installation. That
range of addresses can easily be excluded to prevent violating your contractual agreement with the
vendor.
l
The Provider Edge (PE) routers have addresses that NNMi ICMP ping commands cannot reach or
have addresses that you want to exclude from Subnet views.
Note: The node and interface associated with any address identified in your Excluded IP Address filter
shows up in the topology database and maps.
Carefully select the addresses for your Excluded IP Addresses filter. Do not populate the Excluded IP
Addresses filter with the addresses associated with SNMPv1/SNMPv2c agents or SNMPv3 engines (the
Management Addresses). See "Configure an Excluded IP Addresses Filter" (on page 153) to learn how to
exclude an address or range of addresses from discovery.
For details about how Spiral Discovery works:
Filters to Exclude Certain Interfaces from Discovery
When configuring Spiral Discovery in NNMi, sometimes it is useful to exclude certain interfaces or interface
types from discovery and monitoring.
Once configured as an excluded interface:
l
l
The interface's membership status in groups is removed:
n
Connection
n
Router Redundancy Group (NNMi Advanced)
n
Port Aggregation (NNMi Advanced)
n
Link Aggregation
n
VLAN
The interface's relationship to other objects is canceled:
n
Node
n
Address
Page 120 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
n
l
VLAN Port
During the next discovery cycle, NNMi automatically removes any previously discovered data
associated with an excluded interface.
Note: The node associated with any interface identified in your Excluded Interface filter still shows up in
the topology database and maps.
See "Configure an Excluded Interfaces Filter" (on page 155) to learn how to exclude certain interfaces or
interface types from discovery.
For details about how Spiral Discovery works:
Subnet Connection Rules
The NNMi Subnet Connection Rules work only with IPv4 subnets.
Sometimes it is useful to monitor connections in the following categories:
l
Virtual IPv4 tunnel connections within your management domain.
l
Connections to remote sites (across a Service Provider's network or a WAN).
NNMi accomplishes this by following special rules for subnets with prefix lengths between 28 and 31.
These special rules are called Subnet Connection Rules.
These Subnet Connections Rules enable NNMi to draw arbitrary connections on maps where none would
otherwise be detected. If the connection is between two nodes, NNMi draws a standard line on maps. For
example:
If the connection is between more than two nodes, NNMi displays an
icon:
If you double-click the line or the
icon, the Layer 2 Connection form displays and the Topology
Source value is SUBNETCONNECTION.
NNMiprovides a group of predefined Subnet Connection Rules (see "Subnet Connection Rules Provided
by NNMi" (on page 152)). You can edit an existing Subnet Connection Rule or create your own (see
"Configure Subnet Connection Rules" (on page 150)).
If you limit Spiral Discovery to only your Discovery Seeds, NNMi uses the Subnet Connection Rules to
detect connections among those devices.
Page 121 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
If you use Auto-Discovery rules to configure Spiral Discovery, when NNMi detects a subnet prefix between
28 and 31, NNMi uses the Subnet Connection Rules:
1. NNMi checks for an applicable Subnet Connection Rule (see "Subnet Connection Rules Provided by
NNMi" (on page 152)).
2. If a match is found, Spiral Discovery checks the topology database for existing data about each IPv4
address in the subnet. If no data is found for a particular IPv4 address, NNMi issues an SNMP query
to the new IPv4 address. The number of available IPv4 addresses for each valid prefix length is
described in the following table:
Valid Minimum Prefix Length Values (Subnet Mask Length)
Valid Minimum IPv4 Prefix Length Values
Number of Usable IPv4 Addresses
28
14 (16-2=14)*
29
6 (8-2=6)*
30
2 (4-2=2)*
31
2
* Two IPv4 addresses are reserved in each subnet. The first IPv4 address is used for the network
itself and the last IPv4 address is reserved for broadcast.
3. NNMi checks the Excluded IP Addresses list. Any addresses in the list are dropped. For details, see
"Filters to Exclude Certain IP Addresses from Discovery" (on page 120).
4. New IPv4 addresses that respond to SNMP are added to the topology database and available for
monitoring purposes. New IPv4 addresses that do not respond to SNMP are ignored.
5. If the IPv4 address on each end of a connection has an associated interface, NNMi uses the subnet
connection rule to display the connection on map views.
In a Layer 3 Neighbor View map, if NNMi discovers an interface that is connected to more than one
interface, the results of your subnet connection rule look like the following:
Page 122 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
In a Layer 2 Neighbor View map, if NNMi discovers an interface that is connected to more than one
interface, the results of your subnet connection rule look like the following:
See "Configure Subnet Connection Rules" (on page 150) to learn how to configure Subnet Connection
Rules.
For details about how Spiral Discovery works:
Device Profiles and Discovery
You can modify the settings in the Device Profiles to fine-tune Spiral Discovery and the device symbols on
the maps.
You can also use the Configuration → Device Profiles view to see the list of all known system object IDs
(MIBII sysObjectIDs) at the time NNMi released. This list of system object IDs is useful if you want to
expand the range of devices that NNMi discovers. By default, NNMi discovers only routers and switches
(see "SNMP System Object ID Ranges for Discovery" (on page 148)).
See the Advanced Settings section of "Configure Device Profiles" (on page 134) for more information.
For details about how Spiral Discovery works:
Prerequisites for Discovery
NNMi uses SNMP and DNS while discovering and monitoring devices in your network environment. To
ensure accurate network topology information, verify that these prerequisites are working properly:
l
"SNMP Prerequisites" (on page 123)
l
"Well-Configured DNS Prerequisite" (on page 124)
l
"IPv6 Addresses Prerequisite (NNMi Advanced)" (on page 125)
SNMP Prerequisites
Spiral Discovery uses SNMP while detecting devices and connections among the devices in your network
environment. NNMi also uses SNMP as part of monitoring and reporting on the health of devices in your
network environment.
NNMi supports the following SNMP versions:
l
SNMPv1
l
SNMPv2c
l
SNMPv3
NNMi uses information gathered from Routers to establish subnet membership for Layer 3 connections.
Make sure that important Routers in your network environment are SNMP enabled.
Page 123 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
NNMi uses either of the following criteria to identify a Router:
l
Each Router responds with appropriate values for sysServices (1.3.6.1.2.1.1.7) and ipForwarding
(1.3.6.1.2.1.4.1). See RFC 1213-MIB for details.
l
Identify Routers with the Device Profile configuration settings for a particular device type.
You must provide the appropriate SNMP Community Strings to NNMi. See "Configuring Communication
Protocol" (on page 66).
Before configuring NNMi discovery, complete the following steps:
1. Enable SNMP communication on important devices in your network (each device that you want
NNMi to actively monitor).
See the manufacturer's documentation for information about how to configure SNMP on each of your
devices.
n
Establish read community strings for any SNMPv1 or SNMPv2c agents.
n
Establish the appropriate User-based Security Module (USM) level of security for authentication
and privacy for any SNMPv3 agents.
2. Configure NNMi to use the appropriate read community strings or USM settings for your network
environment. See "Configuring Communication Protocol" (on page 66).
Well-Configured DNS Prerequisite
NNMi uses Domain Name System (DNS) to determine relationships between hostnames and IP
addresses. This can result in a large number of nslookup requests.
Tip: To improve the response time for nsLookup, deploy a secondary DNS service on the NNMi
management server or another system on the same subnet as the NNMi management server.
Configure this secondary DNS service to mirror the information from the primary DNS service. Another
option is to use */etc/hosts instead of DNS in small environments.
Use nslookup to Verify DNS Server Configurations
Verify that your DNS servers are well configured to prevent long delays when resolving nslookup
requests. This means the DNS server responding to NNMi nslookup requests has these qualities:
l
The DNS server is an authoritative server and does not forward DNS requests.
l
The DNS server has consistent hostname-to-IP address mappings and IP address-to-hostname
mappings.
l
If your network uses multiple DNS servers, all respond consistently to any particular nslookup request.
Caution: Round-robin DNS (used to do load balancing of web application servers) is not appropriate
because any given hostname can map to different IP addresses over time.
On the NNMi management server, verify that the following configuration settings in your environment:
l
All operating systems: Locate your */etc/hosts file and ensure that the host file contains a
minimum of two entries. When an nslookup command is not successful, this file takes over:
127.0.0.1 (loopback loghost) or ::1
<NNMi_server_address> (the IP address of the NNMi management server)
Page 124 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
If your NNMi management server participates in a high availability (HA) environment, the virtual server
name and IP-address is required in the */etc/hosts file in addition to the physical server name and
IP-address.
Windows: The following registry key determines the location of this file:
\HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DataBasePath
UNIX: This file is in the /etc directory.
l
Windows: Use the Control Panel to navigate to your Network and Internet Connections configuration,
Network Connections, Local Area Connections, Support tab, and click the Details button. Verify that all
identified DNS servers provide consistent hostname-to-IP address mappings and IP address-tohostname mappings.
l
UNIX: Ensure that the nslookup search path resolves to the nsswitch.conf file. See the
nsswitch.conf(4) manpage that was provided with your operating system. Verify that all identified DNS
servers provide consistent hostname-to-IP address mappings and IP address-to-hostname mappings.
Exclude Problem Devices from nmlookup
You can populate two files that instruct nslookup to exclude certain addresses. The benefits of doing this
are as follows:
l
Speed up Spiral Discovery.
l
Keep network traffic generated by NNMi to a minimum.
If you know there are problems with the DNS configuration in your network domain (hostnames or
addresses that do not resolve properly), instruct NNMi to avoid nslookup requests for unimportant
devices.
To identify problem devices, create the following two files prior to configuring NNMi discovery. NNMi never
issues a DNS request for hostnames or IP addresses identified in these files:
l
hostnolookup.conf — Enter fully-qualified hostnames or wildcards that identify groups of hostnames.
l
ipnolookup.conf — Enter fully-qualified IP addresses or wildcards that identify groups of IP addresses.
Use an ASCII editor to populate the files. Place the files in the following location on the NNMi management
server:
l
Windows:
%NnmDataDir%\shared\nnm\conf\
l
UNIX:
/var/opt/OV/shared/nnm/conf/
IPv6 Addresses Prerequisite (NNMi Advanced)
To discover and monitor Both IPv4 and IPv6 IP addresses, the settings in the nms-jboss.properties file
must first be configured.
NNMi Advanced. If the NNMi administrator wants NNMi to access and monitor IPv6 addresses, NNMi must
be configured to do so. See the "Configuring NNMi Advanced for IPv6" chapter in the HP Network Node
Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals. One of the configuration steps explains how to
make changes to the nms-jboss.properties file. Settings in the nms-jboss.properties file also
partially control how NNMi determines the Management Address for each node:
Page 125 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
l
Prefer IPv4
l
Prefer IPv6
l
No Preference (either IPv4 or IPv6)
To check NNMi for the status of the IPv6 feature in your networking environment, click Help → System
Information and navigate to the Server tab.
In the Management Server section, locate the following attributes and their current values:
l
IPv6 Address: Displayed if the NNMi management server has an IPv6 address.
l
IPv6 Management:
l
n
Enabled
n
Disabled (see the HP Network Node Manager i Software Deployment Reference)
n
Not Licensed (requires NNMi Advanced)
IPv6 Communication:
Displayed if NNMi IPv6 management is enabled.
n
Enabled
n
Disabled (see the HP Network Node Manager i Software Deployment Reference)
n
Not available (no IPv6 Address on management server)
Determine Your Approach to Discovery
Discover and monitor only the network devices that you and your team consider to be important. Take any
approach that makes sense to you.
Tip: See the following examples for ideas. Print one or more of the following topics to use as a guide when
you are configuring NNMi discovery.
Maintain absolute control over what is discovered.
l
"Do Not Use Auto-Discovery Rules" (on page 127)
Configure Spiral Discovery to make decisions about what is discovered.
Create one or more Auto-Discovery Rules that define the boundaries of what is important to you and your
team:
l
"Routers and Switches Discovered" (on page 127) (Auto-Discovery Rules default behavior)
l
"All SNMP Devices Discovered" (on page 128) (more than Routers and Switches)
l
"Everything Discovered" (on page 129) (all SNMP enabled devices and all Non-SNMP devices)
l
"All Devices from a Specific Vendor Discovered" (on page 131)
Fine tune Spiral Discovery behavior.
Identify the things your team is not interested in monitoring:
l
"Limit Sources of Neighbor Information" (on page 132)
l
"Exclude Problem IP Addresses from Discovery" (on page 133)
Page 126 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
l
"Exclude Problem Interfaces from Discovery" (on page 133)
l
"Specific System Object IDs Not Discovered" (on page 133)
Do Not Use Auto-Discovery Rules
If you want NNMi to discover only what you specify, use these guidelines.
Note: After you set your configuration according to these guidelines, when a new device is added to your
network, NNMi does not discover that device unless you configure another discovery seed to
identify that device.
Configuration Steps to Discover Only What You Specify
Task
How
Do not include any Auto-Discovery Rules.
None are required
for this strategy.
In the Discovery Seeds settings, designate the hostname (not case-sensitive) or
IP address of each device you want NNMi to discover and configure NNMi to
monitor your SNMP devices. See "Monitoring Network Health" (on page 213).
"In the Console,
Configure
Discovery Seeds "
(on page 157)
Note: You control how often Spiral Discovery checks the discovered nodes based on a Rediscovery
Interval setting. See "Adjust the Rediscovery Interval" (on page 137) for more information.
Routers and Switches Discovered
If you want Spiral Discovery to automatically find devices on your network, use these guidelines. By
default, Auto-Discovery Rules apply only to routers and switches. If you want to discover more devices, see
"All SNMP Devices Discovered" (on page 128) or "Everything Discovered" (on page 129).
Note: After you set your configuration according to these guidelines, when a new router or switch is added
to your network, you do not need to do anything. NNMi discovers it during the next discovery cycle.
Configuration Steps to Discover Only Routers and Switches
Task
How
Create an Auto-Discovery Rule. Set the following attribute values:
"Configure Auto-Discovery
Rules" (on page 139)
l
Enter Ordering
It is recommended that you use Ordering number 500. This
provides flexibility if you want to expand or limit Spiral Discovery
behavior later by creating additional rules with higher or lower
Ordering numbers.
l
Enable
l
Disable
Discover Any SNMP Device
l
Disable
Discover Non-SNMP Devices
Discover Included Nodes
Create one or more IP Ranges settings that identify the entire scope of
the addresses in your network domain:
Enter IP Range
Page 127 of 1087
(at least one)
"IP Address Ranges for AutoDiscovery" (on page 143)
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Task
How
Set Range Type
Optional. NNMi can use
Enable Ping Sweep (instead of or in
addition to discovery seeds, see below) to gather neighbor information.
"Ping Sweep (as a starting
point)" (on page 118)
NNMi Advanced. Ping Sweep
works only with IPv4
addresses, not IPv6
addresses.
If you want Spiral Discovery to find all routers and switches. Do not
create any System Object ID Ranges.
If you want to limit Spiral Discovery to only the vendor/make/model of
routers and switches that you specify, create one or more System
Object ID Ranges. Your list must include everything you want Spiral
Discovery to find.
Optional. In the Discovery Seeds settings, designate one or more
hostnames (not case-sensitive) or IP addresses. Consider using
devices with the largest neighbor data. For example, a good choice
would be a core router. The discovery seeds become the starting points
from which Spiral Discovery explores your network.
"SNMP System Object ID
Ranges for Discovery" (on
page 148)
Tip: Navigate to the
Configuration workspace,
and select the Device
Profiles view to see all
known system object IDs at
the time NNMi released.
"In the Console, Configure
Discovery Seeds " (on page
157)
Note: You control how often Spiral Discovery runs by designating the Rediscovery Interval setting. See
"Adjust the Rediscovery Interval" (on page 137) for more information.
If you want to fine tune the Spiral Discovery results, see:
l
"All Devices from a Specific Vendor Discovered" (on page 131) (more than routers and switches from
the vendor)
l
"Limit Sources of Neighbor Information" (on page 132) (less than all routers and switches)
l
"Specific System Object IDs Not Discovered" (on page 133) (less than all routers and switches)
l
"Exclude Problem IP Addresses from Discovery" (on page 133)
All SNMP Devices Discovered
If you want Spiral Discovery to find any device that has a working SNMP agent, use these guidelines.
However, this strategy may cause you to reach your license limit very quickly. Consider defining additional
Auto-Discovery Rules to limit this strategy. (See "Specific System Object IDs Not Discovered" (on page
133), or "Limit Sources of Neighbor Information" (on page 132). See also "Filters to Exclude Certain IP
Addresses from Discovery" (on page 120)).
Note: When a new SNMP-supported device is added to your network, you do not need to do anything.
NNMi discovers it during the next discovery cycle.
Page 128 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Configuration Steps to Discover All Devices that Have SNMP Agents
Task
How
Create an Auto-Discovery Rule. Set the following attribute values:
"Configure AutoDiscovery Rules" (on
page 139)
l
Enter Ordering
It is recommended that you use Ordering number 500. This provides
flexibility if you want to expand or limit Spiral Discovery behavior later by
creating additional rules with higher or lower Ordering numbers.
l
Enable
Discover Included Nodes
l
Enable
Discover Any SNMP Device
l
Disable
Discover Non-SNMP Devices
Note: This strategy may cause you to reach your licensed capacity very quickly.
See "Extend a Licensed Capacity" (on page 1013).
Create one or more IP Range settings that identify the entire scope of the
addresses in your network domain:
Enter IP Range
"IP Address Ranges
for Auto-Discovery"
(on page 143)
(at least one)
Set Range Type
Optional. NNMi can use
Enable Ping Sweep (instead of or in addition to
discovery seeds, see below) to gather neighbor information.
"Ping Sweep (as a
starting point)" (on
page 118)
NNMi Advanced.
Ping Sweep works
only with IPv4
addresses, not IPv6
addresses.
Do not create any System Object ID Ranges. When Discover Any SNMP
Device is enabled and no ranges are specified, all SNMP devices are
discovered (every sysObjectID that responds to an SNMP query).
Optional. In the Discovery Seeds settings, designate one or more hostnames
(not case-sensitive) or IP addresses. Consider using devices with the largest
neighbor data. For example, a good choice would be a core router. The
discovery seeds become the starting points for Spiral Discovery.
"In the Console,
Configure Discovery
Seeds " (on page
157)
Note: You control how often Spiral Discovery runs by designating the Rediscovery Interval setting.
"Adjust the Rediscovery Interval" (on page 137) for more information.
Everything Discovered
If you want Spiral Discovery to find all devices in your network, use these guidelines. However, this
strategy may cause you to reach your licensed capacity very quickly. Consider defining additional AutoDiscovery Rules to limit this strategy. (See "All Devices from a Specific Vendor Discovered" (on page 131),
"Specific System Object IDs Not Discovered" (on page 133), or "Limit Sources of Neighbor Information" (on
page 132). See also "Filters to Exclude Certain IP Addresses from Discovery" (on page 120)).
Page 129 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
If the device does not support SNMP, NNMi queries DNS to determine the hostname. If this hostname
matches another non-SNMP node, NNMi merges the information to create only one node with multiple
associated addresses to preserve licensed capacity limits for discovered nodes.
Note: After you set your configuration according to these guidelines, when a new device is added to your
network, you do not need to do anything. NNMi discovers it during the next discovery cycle.
Configuration Steps to Discover Everything
Task
How
Create an Auto-Discovery Rule. Set the following attribute values:
"Configure AutoDiscovery Rules" (on
page 139)
l
Enter Ordering
It is recommended that you use Ordering number 500. This provides
flexibility if you want to expand or limit Spiral Discovery behavior later by
creating additional rules with higher or lower Ordering numbers.
l
Enable
Discover Included Nodes
l
Enable
Discover Any SNMP Device
l
Enable
Discover Non-SNMP Devices
Note: This strategy may cause you to reach your licensed capacity very quickly.
See "Extend a Licensed Capacity" (on page 1013). Consider adding your
non-SNMP devices using seeds instead of selecting the Discover NonSNMP Devices option.
Create one or more IP Ranges settings that identify the entire scope of the
addresses in your network domain:
Enter IP Range
"IP Address Ranges
for Auto-Discovery"
(on page 143)
(at least one is required)
Set Range Type
Optional. NNMi can use
Enable Ping Sweep (instead of or in addition to
discovery seeds, see below) to gather neighbor information.
"Ping Sweep (as a
starting point)" (on
page 118)
NNMi Advanced.
Ping Sweep works
only with IPv4
addresses, not IPv6
addresses.
Do not include any System Object ID Ranges. When Discover All SNMP
Devices is enabled and no ranges are specified, all SNMP devices are
discovered (every sysObjectID that responds to an SNMP query).
Optional. In the Discovery Seeds settings, designate one or more hostnames
(not case-sensitive) or IP addresses. Consider using devices with the largest
neighbor data. For example, a good choice would be a core router. The
discovery seeds become the starting points for Spiral Discovery.
"In the Console,
Configure Discovery
Seeds " (on page
157)
Note: You control how often Spiral Discovery runs by designating the Rediscovery Interval setting. See
"Adjust the Rediscovery Interval" (on page 137) for more information.
Page 130 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
All Devices from a Specific Vendor Discovered
If you want to expand Spiral Discovery to all devices manufactured by a specific vendor (more than routers
and switches), use these guidelines.
To implement this strategy, you must create two Auto-Discovery Rules (see prerequisite). The prerequisite
rule configures Spiral Discovery to find any router or switch, regardless of vendor.
Note: After you set your configuration according to these guidelines, when a new device is added to your
network, you do not need to do anything. NNMi discovers or skips devices according to your
configuration choices.
Prerequisite: Create an Auto-Discovery Rule that uses IP address ranges to specify the outer limits of your
network management domain. This rule instructs Spiral Discovery to find devices manufactured by
any vendor. See "Routers and Switches Discovered" (on page 127), "All SNMP Devices
Discovered" (on page 128) or "Everything Discovered" (on page 129).
Configuration Steps to Discover All Devices from Specific Vendors
Task
How
Create an Auto-Discovery Rule. Set the following
attribute values:
"Configure Auto-Discovery Rules" (on page 139)
l
Enter Ordering
It is recommended that you use Ordering number
400. This rule must have a lower number than
the prerequisite rule.
l
Enable
Discover Included Nodes
l
Enable
Discover Any SNMP Device
l
Disable
Discover Non-SNMP Devices
Create one or more IP Ranges settings that identify
the entire scope of the addresses in your network
domain:
Enter IP Range
"IP Address Ranges for Auto-Discovery" (on
page 143)
(at least one)
Set Range Type
When Discover Any SNMP Devices is enabled and
you specify one or more System Object ID Ranges,
only the sysObjectIDs you specify are discovered.
Create one or more System Object ID Ranges
settings. Enter the SNMP sysObjectID prefix that
identifies each vendor for the devices you want to
discover.
For example, to include all HP devices, use the
following prefix:
1.3.6.1.4.1.11.
Enter System Object ID Prefix
Set Range Type
Page 131 of 1087
"SNMP System Object ID Ranges for Discovery"
(on page 148)
Tip: Navigate to the Configuration workspace,
and select the Device Profiles view to see all
known system object IDs at the time NNMi
released.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Note:You control how often Spiral Discovery runs by designating the Rediscovery Interval setting.
"Adjust the Rediscovery Interval" (on page 137) for more information.
Limit Sources of Neighbor Information
If you want Auto-Discovery to never request neighbor information from certain addresses within your
management domain, use these guidelines. In other words, Auto-Discovery will not use these addresses
as resources for further discovery.
Note: The addresses identified in your IP address Range might show up in the topology database if their
neighbors provide information about them.
To implement this strategy, you must create two Auto-Discovery Rules (see prerequisite).
Prerequisite: Create an Auto-Discovery Rule that uses IP address ranges to specify the outer limits of your
network management domain. See "Routers and Switches Discovered" (on page 127), "All SNMP
Devices Discovered" (on page 128) or "Everything Discovered" (on page 129).
Configuration Steps to Exclude Some IP addresses from Providing Neighbor Data
Task
How To
Create an Auto-Discovery Rule. Set the following attribute values:
"Configure AutoDiscovery Rules" (on
page 139)
l
Enter Ordering
It is recommended that you use Ordering number 100. This rule must have a
lower number than the prerequisite rule.
l
Disable
Discover Included Nodes
l
Disable
Discover Any SNMP Device
l
Disable
Discover Non-SNMP Devices
This strategy instructs NNMi to "not gather neighbor information " from certain
addresses. No devices matching that rule's criteria are discovered and added to
the topology database unless:
l
The device's address is a discovery seed.
See "Specify Discovery Seeds: Initial Routers or Specific Nodes to be
Discovered" (on page 156) to learn how to establish discovery seeds.
l
The device's address is reported as a neighbor to another discovered
address.
If you want to ensure that an address is never added to the NNMi database,
use the "Configure an Excluded IP Addresses Filter" (on page 153) or
"Configure an Excluded Interfaces Filter" (on page 155) settings.
Create one or more IP Ranges settings that identify all addresses from which
Auto-Discovery never requests neighbor information.
Enter IP Range
"IP Address Ranges
for Auto-Discovery"
(on page 143)
(at least one)
Set Range Type
Create a list of IP addresses that NNMi should never discover.
"Configure an
Excluded IP
Addresses Filter" (on
Page 132 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Task
How To
page 153)
Note: You control how often Spiral Discovery runs by designating the Rediscovery Interval setting. See
"Adjust the Rediscovery Interval" (on page 137) for more information.
Exclude Problem IP Addresses from Discovery
If you want Spiral Discovery to never discover certain IP addresses, use these guidelines.
Note: The node and interface associated with any address identified in your Excluded IP Address filter are
added to the topology database and maps.
Configuration Steps to Exclude Certain IP Addresses from Spiral Discovery
Task
How To
Create at least one Excluded IP Addresses
filter.
"Configure an Excluded IP Addresses Filter" (on page
153)
Note: You control how often Spiral Discovery runs by designating the Rediscovery Interval setting. See
"Adjust the Rediscovery Interval" (on page 137) for more information.
Exclude Problem Interfaces from Discovery
If you want Spiral Discovery to never discover certain interfaces, use these guidelines.
Note: The node associated with any interface identified in your Excluded Interfaces filter is added to the
topology database and maps.
Configuration Steps to Exclude Certain Interfaces from Spiral Discovery
Task
How To
Create at least one Excluded Interface filter.
"Configure an Excluded Interfaces Filter" (on page 155)
Note: You control how often Spiral Discovery runs by designating the Rediscovery Interval setting. See
"Adjust the Rediscovery Interval" (on page 137) for more information.
Specific System Object IDs Not Discovered
If you want to limit Spiral Discovery to never discover certain device makes/models, use these guidelines.
You must be able to identify the devices using SNMP system object IDs.
To implement this strategy, you must create two Auto-Discovery Rules (see prerequisite).
Note: After you set your configuration according to these guidelines, when a new device is added to your
network, you do not need to do anything. NNMi discovers or skips devices according to your
configuration choices.
Prerequisite: Create an Auto-Discovery Rule that uses IP address ranges to specify the outer limits of your
network management domain. See "Routers and Switches Discovered" (on page 127), "All SNMP
Devices Discovered" (on page 128) or "Everything Discovered" (on page 129).
Page 133 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Configuration Steps to Exclude Some System Object IDs from Spiral Discovery
Task
How To
Create an Auto-Discovery Rule. Set the following attribute
values:
"Configure Auto-Discovery Rules"
(on page 139)
l
Enter Ordering
It is recommended that you use Ordering number 200. This
rule must have a lower number than the prerequisite rule.
l
Disable
Discover Included Nodes
l
Disable
Discover Any SNMP Device
l
Disable
Discover Non-SNMP Devices
Note: This strategy instructs NNMi to "not discover" certain things.
Do not include any IP Ranges. When no IP address ranges are
defined within an Auto-Discovery Rule, your system object ID
ranges take precedence over all Auto-Discovery Rules that have
higher Ordering numbers than this Auto-Discovery Rule.
Note: NNMi automatically treats any Auto-Discovery Rules
without any IP Range as if
Discover Included Nodes
were disabled.
Create one or more System Object ID Ranges settings. Enter
the SNMP sysObjectID that identifies the make/model of the
SNMP device that you do not want to discover.
Enter System Object ID Prefix
Set Range Type
"SNMP System Object ID Ranges for
Discovery" (on page 148)
Tip: Navigate to the Configuration
workspace, and select the
Device Profiles view to see all
known system object IDs at the
time NNMi released.
Note: You control how often Spiral Discovery runs by designating the Rediscovery Interval setting. See
"Adjust the Rediscovery Interval" (on page 137) for more information.
Configure Device Profiles
According to industry standards (RFC 1213, MIB II), each combination of vendor, device type, and model
number is assigned a unique SNMP system object ID (sysObjectID). For example, all Cisco 6500 series
switches have the same sysObjectID prefix: .1.3.6.1.4.1.9.*
HP provides well over three thousand preconfigured Device Profiles, one for each known sysObjectID at
the time NNMi released.
NNMi uses Device Profiles (which equate to sysObjectIDs) to control certain types of behavior:
l
Spiral Discovery determines the closest matching device profile, and uses the device profile settings to
control certain attribute values for the discovered device. The Device Profile also influences the
following:
n
Auto-Discovery Rules can provide a list of sysObjectIDs that expand the default discovery behavior
(beyond routers and switches) or prevent troublesome device types from being discovered.
Page 134 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
The Node Name value might be affected, depending on your choices, see "Configure the Node
Name Strategy" (on page 138).
n
l
When Node Groups are defined based on system object IDs, the State Poller Service monitors devices
based on attribute values in the device profiles. Device Profile settings determine how State Poller
detects renumbered interfaces.
l
In Map views, the background shape of map icons is determined by the Device Category. See About
Map Symbols for an example of each available shape. There is also a Force Device attribute that
enables category overrides in troublesome situations.
Tip: To quickly locate the device profile settings for a particular network device, sort or filter the Device
Profiles view by clicking the heading for the Device Vendor, Device Model, or Device Category
columns.
To access the device profile definition for a particular device type:
1. Navigate to the Device Profile view.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Device Profiles view.
2. Do one of the following:
n
To create a device profile, click the
n
To edit a device profile, click the
to edit.
New icon.
Open icon in the row representing the configuration you want
3. Modify the settings as needed:
Caution: When you make a change, NNMi must update all references to device profiles. This can
take some time and slow down your system. Consider making this change during a slow time
in your network environment.
n
The basic settings Device Category attribute value modifies NNMi behavior for Spiral Discovery
and map symbols.
Caution: If you make changes to a Menu Item provided by NNMi, those changes are at risk of
being overwritten in the future. See Author form for important information.
n
The advanced settings control NNMi behavior for Spiral Discovery and Node name selection. For
example, instruct NNMi to treat a certain device type as a Router.
4. Click
Save and Close. NNMi applies your changes during the next regularly scheduled discovery
cycle. To apply the changes immediately, use Actions → Configuration Poll. See Using Actions to
Perform Tasks for more information.
Configure Discovery
NNMi uses Simple Network Management Protocol (SNMP read-only queries), and a variety of
communication protocols to discover the devices within the network management domain that you define.
See "How Spiral Discovery Works" (on page 113) for more information.
By default, NNMi does the following (and you can change these default settings):
l
Drops all non-SNMP nodes from discovery.
l
Discovers routers and switches.
Page 135 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
If you want NNMi to discover non-SNMP devices or more than routers and switches, use Auto-Discovery
Rules that configure discovery behavior to meet your needs. Or add the specific devices as discovery
seeds.
To configure the NNMi Discovery Process, do the following:
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Discovery Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
3. Make your configuration choices (see table).
4. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval. To apply the changes immediately, use Actions → Configuration Poll.
See Using Actions to Perform Tasks for more information.
Discovery Configuration Tasks
Task
How
"Determine Your
Approach to
Discovery" (on page
126)
Read these guidelines to understand how to configure discovery for the types of
devices you want to discover, including the following:
For strategies to discover devices:
For strategies to prevent specific devices from being discovered:
"Adjust the
Rediscovery Interval"
(on page 137)
Optional. Use the Discovery Configuration workspace to modify the global
discovery interval setting. The Global Control setting for Rediscovery Interval
controls the frequency that NNMi uses for network discovery traffic.
"Configure Ping
Sweep Global
Settings" (on page
137)
NNMi Advanced. Ping Sweep works only with IPv4 addresses, not IPv6
addresses.
"Configure the Node
Name Strategy" (on
page 138)
Optional. Use the Discovery Configuration workspace to specify a node naming
strategy. The Global Control settings for Node Name enable you to choose the
most meaningful name for devices in your environment.
"Configure AutoDiscovery Rules" (on
page 139)
Optional. Use the Auto-Discovery Rules tab to specify any IP address ranges or
MIB II sysObjectID ranges (or both) that you want NNMi to use for automatic
discovery.
Optional. Use the Discovery Configuration workspace to configure the starting
points for Auto-Discovery. The choices are Discovery Seeds or Ping Sweep
within Auto-Discovery Rules (ICMP ping commands) or both. The Global Control
settings for Spiral Discovery Ping Sweep Control provide control across all AutoDiscovery Rules.
Within each Rule you can specify whether Ping Sweep is used as a starting point
(in addition to or instead of discovery seeds). NNMi Advanced. Ping Sweep
works only with IPv4 addresses, not IPv6 addresses.
"Configure an
Excluded IP
Addresses Filter" (on
page 153)
Optional. Use the Excluded IP Addresses tab to provide a list of specific
addresses or ranges of addresses that you want NNMi to never discover or
monitor.
Page 136 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Task
How
"Configure Subnet
Connection Rules"
(on page 150)
Optional. Use the Subnet Connection Rules tab to connect interfaces on devices
that do not respond to Layer 2 Discovery protocols (for example, WAN edge
devices).
"Specify Discovery
Seeds: Initial Routers
or Specific Nodes to
be Discovered" (on
page 156)
Optional. Use the Discovery Seeds tab to specify nodes to be discovered or to
indicate which nodes are used as starting points for your Auto-Discovery Rules.
Tip: Use the Discovery Seeds tab to verify that NNMi successfully located each
Discovery Seed that you provided. See "Discovery Seed Results" (on page
165).
Adjust the Rediscovery Interval
When configuring Spiral Discovery, you determine how often network traffic is generated to gather and
verify information about your network management domain. This time interval controls how frequently
information is gathered about nodes, interfaces, IP addresses, subnets, VLANs, and connections in the
network. See "Rediscovery Intervals" (on page 115) for more information.
To adjust the rediscovery cycle interval:
1. Navigate to the Discovery Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
2. Locate the Global Control settings.
3. In the Rediscovery Interval attribute, set the time interval that Spiral Discovery waits between
information gathering cycles.
The default is 24 hours between cycles. The minimum is 1 hour. Maximum 99 days.
Make sure the interval value provides plenty of time so Spiral Discovery cycles do not overlap. The
larger your network environment, the longer the time required to complete a Spiral Discovery cycle.
4. Click
Save and Close to apply your changes.
Configure Ping Sweep Global Settings
You have two choices for Auto-Discovery starting points. Use either or both to best advantage in your
network environment:
l
Discovery Seeds: You designate specific hostnames (not case-sensitive) or IP addresses where AutoDiscovery starts gathering neighbor information.
For details see "Discovery Seeds (as a starting point)" (on page 118). For information about creating
Discovery Seeds, see "Specify Discovery Seeds: Initial Routers or Specific Nodes to be Discovered"
(on page 156).
l
Ping Sweep: NNMi issues ICMP pings to certain addresses to find new nodes. For details, see "Ping
Sweep (as a starting point)" (on page 118). Note that with NNMi Advanced, Ping Sweep works only
with IPv4 addresses, not IPv6 addresses.
Ping Sweep uses the current default ICMP interval and timeout settings from the Communications
Configuration settings. See "Configure Default SNMP and ICMP Protocol Settings" (on page 67).
To configure the global Auto-Discovery setting for Ping Sweep:
Page 137 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
1. Navigate to the Discovery Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
2. Navigate to the Global Control settings.
3. Designate the global setting for Ping Sweep. Your choice determines how Spiral Discovery uses
ICMP ping commands for the discovery process in your network environment:
n
Each Rule (as configured)— The instructions for Ping Sweep within each Auto-Discovery Rule
configuration are followed exactly.
To configure Ping Sweep for a specific Auto-Discovery Rule, see "IP Address Ranges for AutoDiscovery" (on page 143).
n
All Rules— Ping Sweep is applied for all of your current Auto-Discovery Rules. This overrides the
Ping Sweep settings within each rule.
n
None of the Rules— Ping Sweep is not used for any of your current Auto-Discovery Rules. This
overrides the Ping Sweep settings within each rule. This is useful to temporarily suspend issuing
any ping commands within your network.
Note: If things don't work as expected, check whether ICMP is allowed (see if "Communication
Region Form" (on page 80)).
4. Designate the Sweep Interval (days/hours) that controls how often Spiral Discovery reissues ICMP
Ping for each address. The minimum allowed Sweep Interval setting is 1 hour. Maximum 99 days.
5. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval.
Configure the Node Name Strategy
When configuring discovery in NNMi, you control how the Name attribute on the Node form is populated.
For details see "Discovery Node Name Choices" (on page 115).
Note: NNMi can automatically convert the Node Name to all uppercase or all lowercase (if configured to
do so by the NNMi administrator). See the information about the nms-topology.properties file in
the HP Network Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals.
To resolve issues about choosing the Name value, NNMi follows a sequence of rules. If NNMi is unable to
determine a Name based on your three choices, the node name is determined using the NNMi factory
defaults for these three choices (see list in step 3).
The node Name shows up beneath the node symbol on the maps and in the Name column on table views.
To control how node names are determined for your network devices:
1. Navigate to the Discovery Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
2. Locate the Node Name Resolution attributes on the left side of the form (see table).
3. Specify the three-level hierarchy for node naming decisions.
Page 138 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Short name and full name are related. The short name is everything before the first period in the full
name. For example, full name cisco5500.abc.example.com and the short name cisco5500.
Select among the following choices. Use each choice only one time:
n
Short DNS Name – (first by default) Use the group of characters prior to the first period in your inhouse DNS naming standards. See "Discovery Node Name Choices" (on page 115) for possible
issues with using DNS names.
n
Fully Qualified DNS Name – Use the full in-house DNS naming standards.
n
Short sysName – (second by default) Use the group of characters prior to the first period in the
current MIB II sysName value established by the administrator for each SNMP enabled device.
See "Discovery Node Name Choices" (on page 115) for possible issues with using sysName.
n
Full sysName – Use the full current MIB II sysName value established by the administrator for
each SNMP enabled device.
n
IP Address – (third by default) Use the IP address. If the node responds to SNMP, the SNMP
Management Address is used. For non-SNMP nodes, name is set to either a discovery seed
address associated with this node or a neighbor address gathered by Spiral Discovery along the
path to this node.
Note: If you listed the address in your Excluded IP Address filter, Spiral Discovery skips that
address. See "Exclude Problem IP Addresses from Discovery" (on page 133).
4. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval. To apply the changes immediately, use Actions → Configuration Poll.
See Using Actions to Perform Tasks for more information.
Node Name Resolution Settings
Attribute
Description
First
Choice
Click the drop-down list and choose the predefined node name strategy you want discovery
to use first.
Second
Choice
Click the drop-down list and choose the predefined node name strategy you want discovery
to use if the first choice fails.
Third
Choice
Click the drop-down list and choose the predefined node name strategy you want discovery
to use if the second choice fails.
Configure Auto-Discovery Rules
Auto-Discovery Rule configuration settings control Spiral Discovery behavior (for details see "AutoDiscovery Rules" (on page 119)):
l
Rules define the outer limits of discovery.
l
Rules expand or reduce the types of devices that are discovered and added to the topology database.
Before you start, have a clear idea of what you want to accomplish, see "Determine Your Approach to
Discovery" (on page 126).
If you do not configure any Auto-Discovery Rules, Spiral Discovery is limited to only discovery seeds. See
"Discovery Seeds (as a starting point)" (on page 118) for more information.
To configure Auto-Discovery Rules, do the following:
Page 139 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Auto-Discovery Rules tab.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
c. Select the Auto-Discovery Rules tab.
3. Make your configuration choices (see table).
n
To establish a rule, click the
n
To edit a rule, click the
and continue.
n
To delete a rule, select a row, and click the
n
To refresh the list, click the
New icon, and continue.
Open icon in the row representing the configuration you want to edit,
Delete icon.
Refresh icon.
4. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval. To apply the changes immediately, use Actions → Configuration Poll.
See Using Actions to Perform Tasks for more information.
Auto-Discovery Rule Configuration Tasks
Task
How
"Configure Basic Settings
for the Auto-Discovery
Rule" (on page 141)
Provide the basic requirements for an Auto-Discovery Rule configuration:
l
The name of the rule.
l
Specify the order in which Spiral Discovery applies this rule.
l
Specify how ICMP and SNMP protocols are used for this segment of
discovery.
l
Designate whether devices identified by this rule are Discovered or
Rejected during the Spiral Discovery process.
Page 140 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Task
How
Rule Criterion
"IP Address Ranges for Auto-Discovery" (on page 143)
Use IP addresses with wildcards to specify the area you want Spiral
Discovery to find in your network environment. You decide whether Ping
Sweep is used for this segment of discovery.
NNMi Advanced. Ping Sweep works only with IPv4 addresses, not IPv6
addresses.
"SNMP System Object ID Ranges for Discovery" (on page 148)
Use industry standard System Object IDs to control Spiral Discovery:
l
Expand Spiral Discovery to "include" additional device types to be
discovered within the range of IP addresses you specify in this AutoDiscovery Rule.
Note: requires that you also enable
l
Enable Any SNMP Device.
Instruct Spiral Discovery to "ignore" (never discover, exclude) specific
troublesome models of routers, switches, or other devices.
Tip: To set this exclusion across all Auto-Discovery Rules, do not set
any IP Address Ranges in the same Auto-Discovery Rule and use
your lowest Ordering number for this Auto-Discovery Rule.
Configure Basic Settings for the Auto-Discovery Rule
The Auto-Discovery Rule settings determine which methods Spiral Discovery applies when discovering
the part of your network defined in the rule.
To configure this Auto-Discovery Rule:
1. Navigate to the Auto-Discovery Rule form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
c. Locate the Auto-Discovery Rules tab.
d. Do one of the following:
o To establish a rule, click the
o To edit a rule, click the
New icon, and continue.
Open icon in the row representing the configuration you want to
edit, and continue.
o To delete a rule, select a row, and click the
Delete icon.
2. Provide the required basic settings (see the Basics for this Auto-Discovery Rule table).
3. There are many ways to implement discovery. Before you start this step, "Determine Your Approach
to Discovery" (on page 126).
Configure one or more ranges, to identify the devices you want to discover.
n
"IP Address Ranges for Auto-Discovery" (on page 143)
n
"SNMP System Object ID Ranges for Discovery" (on page 148)
Page 141 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
4. Optional. Choose the Final Filter settings for this rule (see the Final Filter for this Auto-Discovery Rule
table).
5. Click
Save and Close to return to the Discovery Configuration form.
6. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval.
7. Optional: Open the Discovery Configuration workspace again and provide a discovery seed for
each address range of this Auto-Discovery Rule. Core routers make the best seeds. See "Specify
Discovery Seeds: Initial Routers or Specific Nodes to be Discovered" (on page 156).
Basics for this Auto-Discovery Rule
Task
How
Name
Give this Auto-Discovery Rule a meaningful name.
Ordering
Determine the order in which the Auto-Discovery Rules are applied. No Duplicate Ordering
numbers are allowed. Each Auto-Discovery Rule ordering number must be unique.
Tip: It is recommended that ordering numbers are incremented by 10s or 100s to provide
flexibility when adding new rules over time.
IP address ranges: If a device falls within two Auto-Discovery Rules, the Auto-Discovery
Rule with the lowest ordering number applies. For example, if an Auto-Discovery Rule
includes certain IP addresses, then no other Auto-Discovery Rules with higher ordering
numbers apply to those addresses.
System Object ID ranges:
Discover
Included
Nodes
l
If no IP address range is included in this Auto-Discovery Rule, then the system object ID
settings take precedence over all Auto-Discovery Rules that have higher Ordering
numbers than this Auto-Discovery Rule.
l
If an IP address range is included in this Auto-Discovery Rule, your system object ID
range applies only within this Auto-Discovery Rule.
If enabled, Auto-Discovery gathers information about neighboring devices and adds
devices to the NNMi database if they meet the rule's criteria. For more information see "AutoDiscovery Rules" (on page 119).
Note: By default NNMi discovers routers and switches. You can expand the number of device
types that NNMi discovers by enabling Discover Any SNMP Device and including
one or more System Object ID Ranges (based on MIB II sysObjectID values). Your
address ranges and system object ID ranges determine which discovered addresses
are added to the NNMi database.
If
l
disabled, Spiral Discovery ignores devices that match this rule unless:
The device's address is a discovery seed.
See "Specify Discovery Seeds: Initial Routers or Specific Nodes to be Discovered" (on
page 156) to learn how to establish discovery seeds.
l
The device's address is reported as a neighbor to another discovered address.
If you want to ensure that an address is never added to the NNMi database, use the
"Configure an Excluded IP Addresses Filter" (on page 153) or "Configure an Excluded
Interfaces Filter" (on page 155) settings.
Notes
Provide any additional useful information about this Auto-Discovery Rule.
Page 142 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Task
How
Type a maximum of 1024 characters. Alpha-numeric, spaces, and special characters (~ ! @ #
$ % ^ & * ( ) _+) are allowed.
Final Filter for this Auto-Discovery Rule
Task
How
Discover
Any SNMP
Device
Note: This value is ignored if Discover Included Nodes is unchecked. However, if you
configure any device as a discovery seed, discovery always adds that device to the
database.
If enabled, discovery gathers information about any device that responds to SNMP
queries (in addition to routers or switches that are discovered by default). These nodes
appear on maps and are monitored.
If disabled, discovery ignores all device types except routers, switches, discovery
seeds, and device types specified in your system object ID ranges. (Routers and switches
are identified by the settings in the device profile.)
Discover
NonSNMP
Devices
Note: This value is ignored if Discover Included Nodes is unchecked. However, if you
configure any device as a discovery seed, discovery always adds that device to the
database.
Non-SNMP devices are those that do not respond to SNMP queries.
If you enable Discover Non-SNMP Devices, note the following:
l
If you do not want NNMi to discover every node in your network, make sure your AutoDiscovery Rules correctly limit the scope of the discovery. See"Determine Your
Approach to Discovery" (on page 126) for more information.
l
Selecting this option may cause you to reach your licensed capacity very quickly. See
"Extend a Licensed Capacity" (on page 1013).
l
If NNMi determines that a non-SNMP node has a hostname matching another nonSNMP node, NNMi merges the information to create only one node and includes any
additional IP address information under the same node.
Non-SNMP nodes might be inaccurately represented under the following
circumstances:
n
One or more non-SNMP nodes in your network use the same hostname.
n
The same non-SNMP node has multiple hostnames.
n
A non-SNMP node name changes (see "Delete Nodes" (on page 170)).
If
enabled, addresses that do not respond to SNMP queries are added to the database.
If
disabled, discovery ignores any address that does not respond to SNMP queries.
IP Address Ranges for Auto-Discovery
Auto-Discovery IP address ranges determine the outer limits for the area controlled by the current AutoDiscovery Rule. You can create multiple IP ranges within one Auto-Discovery Rule. Before you start, have
a clear idea of what you want to accomplish, see "Determine Your Approach to Discovery" (on page 126).
If
Discover Included Nodes, click here for additional information about IP address ranges when
Page 143 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
defining a rule with Discover Included Nodes disabled.
l
Spiral Discovery does not gather neighbor information from the addresses identified in any IP address
range included in this rule. The addresses, themselves, may still show up in the topology database.
Note: Neighbor information is still gathered from IP addresses specifically identified in the discovery
seeds configuration settings.
l
IP address ranges are optional. However, when no IP address range is provided:
n
One or more system object ID (MIB II sysObjectIDs) ranges must be defined. This technique
constricts or extends the types of devices affected by this rule. See "SNMP System Object ID
Ranges for Discovery" (on page 148) for more information.
n
The system object ID range criteria applies to all Discovery Rules with higher Ordering numbers.
If Discover Included Nodes, click here for additional information about IP address ranges when
defining a rule with Discover Included Nodes enabled.
l
At least one IP address range is required to be designated as an Include in rule range type. AutoDiscovery gathers neighbor information from those addresses to extend discovery.
l
Optional. You can configure NNMi to ignore subsets of those IP addresses (an Ignored by rule range,
which means that those addresses are available for other Auto-Discovery Rules).
l
Optional. Specify system object ID (MIB II sysObjectIDs) ranges to be included or ignored. This
technique constricts or extends the types of devices affected by this rule. See "SNMP System Object ID
Ranges for Discovery" (on page 148) for more information.
NNMi discovers any devices that comply with your rule configurations, and creates a record of each device
in the NNMi database. If the device supports SNMP, all addresses for that device are combined into one
Node object. If the device does not support SNMP, NNMi queries DNS to determine the hostname. If this
hostname matches another non-SNMP node, NNMi merges the information to create only one node with
multiple associated addresses.
To specify an Auto-Discovery Rule IP address range:
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Auto-Discovery form.
a. In the Workspace navigation panel, open the Configuration workspace.
b. Select Discovery Configuration.
c. Select the Auto-Discovery Rule tab, and do one of the following:
o To establish an Auto-Discovery Rule, click the
o To edit an Auto-Discovery Rule, click the
New icon.
Open icon in the row representing the
configuration you want to edit.
3. Navigate to the IP Ranges tab.
4. Optional. Decide if you want to use Ping Sweep in this segment of network discovery.
Note: NNMi Advanced - Ping Sweep works only with IPv4 addresses, not IPv6 addresses:
n
Enable Ping Sweep
Auto-Discovery issues a wide range of ICMP ping commands to determine starting points for
Page 144 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Spiral Discovery. For details, see "Ping Sweep (as a starting point)" (on page 118). NNMi only
uses Ping Sweep across a maximum of the last two octets (/16) of the network specified by each
IPv4 IP address range.
If things don't work as expected, check whether Ping Sweep is disabled (see "Configure Ping
Sweep Global Settings" (on page 137)) and check whether ICMP is allowed (see if
"Communication Region Form" (on page 80)).
n
Enable Ping Sweep
Auto-Discovery depends on Discovery Seeds as starting points for Spiral Discovery. For details,
see "Discovery Seeds (as a starting point)" (on page 118) for important information.
5. Optional. To provide an IP address range for this Auto-Discovery Rule, do one of the following:
n
To create an IP range, click the
n
To edit an IP range, click the
edit, and continue.
n
To delete an IP range, select a row, and click the
New icon, and continue.
Open icon in the row representing the configuration you want to
Delete icon.
6. Provide the IP address range information for this Auto-Discovery Rule (see table).
Note: If you choose to not include any IP address ranges in a particular Auto-Discovery Rule, then
you must provide at least one system object ID range (see "SNMP System Object ID Ranges
for Discovery" (on page 148)). And Auto-Discovery Rules without any IP Range must have
Discover Included Nodes disabled in the Auto-Discovery Rule form.
7. Click
Save and Close to return to the Auto-Discovery Rule form.
8. Click
Save and Close to return to the Discovery Configuration form.
9. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval.
Discovery IP Range Form
Name
Description
IP
Range
Note: If you enter an IP address value that represents only one IP address, Auto-Discovery
gathers neighbor information only from the address you enter. (Discovery extends only
one hop out from this address.)
To specify a range of IP addresses for this Auto-Discovery Rule, use one of the following. Pick
one address notation style, combinations of wildcards and CIDR notation are not allowed within
one address range. You can provide multiple address range settings:
l
IPv4 address wildcard notation.
An IPv4 Address range is a modified dotted-notation where each octet is one of the
following:
n
A specific octet value between 0 and 255
n
A low-high range specification for the octet value (for example, "112-119")
n
An asterisk (*) wildcard character which is equivalent to the range expression "0-255"
Note: The following two IPv4 addresses are considered invalid: 0.0.0.0 and 127.0.0.0
Examples of valid IPv4 address wildcards include:
10.1.1.*
10.*.*.*
Page 145 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Name
Description
10.1.1.1-99
10.10.50-55.*
10.22.*.4
10.1-9.1-9.1-9
l
IPv4 Classless Inter-Domain Routing (CIDR) notation.
The CIDR notation specifies the number of consecutive bits in the IPv4 address that must
match.
For example, 10.2.120.0/21
Note: NNMi does not support CIDR subnet mask notation such as,
10.2.120.0/255.255.248.0
Example IPv4 Prefix Length Values
Number of Usable IPv4 Addresses
28
14 (16-2=14)*
29
6 (8-2=6)*
30
2 (4-2=2)*
31
2
* Two IPv4 addresses are reserved in each subnet. The first IPv4 address is used for the
network itself and the last IPv4 address is reserved for broadcast.
l
IPv6 address wildcard notation
Separate each 16-bit value of the IPv6 address with a colon. The 16-bit value can be any of
the following:
n
A specific hexadecimal value between 0 and FFFF (case insensitive).
n
A low-high range specification of the hexadecimal value (for example, 1-1fe).
n
An asterisk (*) wildcard character (equivalent to the range expression 0-ffff).
Note: The standard IPv6 short-hand notation (::) is allowed to express one or more 16-bit
elements of zero (0) values. However, the mixed IPv6/IPv4 dot-notation (for example,
2001:d88::1.2.3.4) is not allowed as an IPv6 address range.
Valid examples of ranges in modified IPv6 address notation include the following:
2001:D88:0:A00-AFF:*:*:*:*
2001:D88:1:*:*:*:*:*
2001:D88:2:0:a07:ffff:0a01:3200-37ff
l
IPv6 Classless Inter-Domain Routing (CIDR) notation
The CIDR notation specifies the number of consecutive bits in the IPv6 address that must
match.
1080:0:a00::/44 (equivalent to modified IPv6 address notation 1080:0:a00a0f:*:*:*:*:*)
For example, valid IPv6 address ranges in CIDR notation include the following:
2001:d88:0:a00::/56 (equivalent to modified IPv6 address notation 2001:D88:0:A00AFF:*:*:*:*)
Page 146 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Name
Description
2001:d88:1::/48 (equivalent to modified IPv6 address notation
2001:D88:1:*:*:*:*:*)
Page 147 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Name
Description
Range
Type
Include in rule - The current Auto-Discovery Rule settings apply to the addresses in this range.
Ignored by rule - The current Auto-Discovery Rule settings do not apply to the addresses in this
range. Use the Ignored by rule setting to identify a subset of addresses within a larger range.
The addresses in the ignored range are available to conform to an Auto-Discovery Rule with a
higher ordering number.
SNMP System Object ID Ranges for Discovery
Vendors are assigned a system object ID (RFC 1213 MIB II sysObjectID) for each type of network device
that they manufacture. This system object ID number is unique for each combination of vendor, device
type, and model number. For example, all Cisco 6509 routers have the same system object ID.
Tip: See "Configure Device Profiles" (on page 134) for more information about system object IDs. In the
Device Profiles view (in the Configuration workspace), you can quickly and easily locate the system
object IDs of devices in your network environment.
System object ID ranges are powerful tools for expanding or limiting discovery behavior. For example,
expand discovery to include more than the default routers and switches, or limit discovery by excluding
specific models of routers and switches. Before you start, have a clear idea of what you want to
accomplish, see "Determine Your Approach to Discovery" (on page 126).
When using system object ID ranges, note the following:
l
When one or more IP address ranges are defined within the Auto-Discovery Rule, your system object
ID ranges apply only within the current Auto-Discovery Rule.
l
When no IP address ranges are defined within the Auto-Discovery Rule, your system object ID ranges
take precedence over all Auto-Discovery Rules that have higher Ordering numbers than this AutoDiscovery Rule.
l
To enable Discover Included Nodes in this rule, at least one IP address range is required. Before any
discovered node is added to the topology database, it must match both IP address range and system
object ID range specifications.
The following table includes examples of how you might want to expand or limit your Spiral Discovery
scope using System Object ID Ranges.
Controlling Spiral Discovery with System Object ID Ranges
Task
Related Topics
Expand Spiral Discovery to include device types in
addition to routers and switches.
"All Devices from a Specific Vendor
Discovered" (on page 131)
Globally exclude one or more specific device types from
Spiral Discovery.
"Specific System Object IDs Not
Discovered" (on page 133)
To specify a system object ID range:
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Discovery System Object ID Range form.
a. From the workspace navigation panel, select the Configuration workspace.
Page 148 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
b. Select Discovery Configuration.
c. Select the Auto-Discovery Rule tab.
d. Do one of the following:
o To create an Auto-Discovery Rule, click the
o To edit an Auto-Discovery Rule, click the
New icon.
Open icon in the row representing the
configuration you want to edit.
e. In the Auto-Discovery Rule form, select the System Object ID Ranges tab.
f. Do one of the following:
o To create a system object ID range, click the
o To edit a system object ID range, click the
New icon, and continue.
Open icon in the row representing the
configuration you want to edit, and continue.
o To delete a system object ID range, click the
Delete icon.
3. Provide one or more System Object ID ranges for this Auto-Discovery Rule (see the table).
Use multiple System Object ID ranges to fine tune your discovery settings.
Note: If you do not include any System Object ID ranges in a particular Auto-Discovery Rule, then
you must provide at least one IP address range in that particular Auto-Discovery Rule (see "IP
Address Ranges for Auto-Discovery" (on page 143)).
Example 1. In an Auto-Discovery Rule with
Discover Included Nodes enabled:
n
Create a definition that includes all HP devices. Use the System Object ID prefix 1.3.6.1.4.1.11
and set the Range Type to Include in rule.
n
Create a definition that excludes any HP Printers. Use the System Object ID prefix
1.3.6.1.4.1.11.2.3.9 and set the Range Type to Ignored by rule. (Order does not matter, now the
printers are always ignored.)
Example 2. In an Auto-Discovery Rule with
Discover Included Nodes disabled:
n
Create a definition that excludes any HP Printers. Use the System Object ID prefix
1.3.6.1.4.1.11.2.3.9 and set the Range Type to Include in rule.
n
Skip step 4, below. HP printers are not discovered within the IP address range of any AutoDiscovery Rules with higher ordering numbers than this rule.
4. Click
Save and Close to return to the Auto-Discovery Rule form.
5. Provide any IP ranges (see "IP Address Ranges for Auto-Discovery" (on page 143)):
n
Optional if
Discover Included Nodes is disabled in the Auto-Discovery Rule form.
n
Required if
Discover Included Nodes is enabled in the Auto-Discovery Rule form.
Click
6. Click
Save and Close to return to the Auto-Discovery Rule form.
Save and Close to return to the Discovery Configuration form.
7. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval.
Page 149 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Discovery System Object ID Range Definition
Attribute
Description
System
Object ID
Prefix
Enter a prefix of an SNMP system object ID, or enter the entire SNMP system object ID. A
partial entry becomes a wildcard.
For example, if you enter 1.3.6.1.4.1.11, discovery finds all HP devices. If you enter
1.3.6.1.4.1.9, discovery finds all Cisco devices.
Note: Do not use dashes or asterisks (*) in your system object ID value.
Range
Type
Include in rule - Instructs Auto-Discovery to find devices matching this system object ID
range.
Ignored by rule - Instructs Auto-Discovery to ignore devices matching this system object ID
range.
Notes
Add any information about this rule that would be useful to you and your team.
Type a maximum of 1024 characters. Alpha-numeric, spaces, and special characters (~ !
@ # $ % ^ & * ( ) _+) are allowed.
Configure Subnet Connection Rules
The NNMi Subnet Connection Rules work only with IPv4 subnets.
For an explanation of how Subnet Connection Rules work, see "Subnet Connection Rules" (on page 121).
If important subnets in your network environment are not automatically connected by Spiral Discovery, edit
a Subnet Connection Rule or create your own.
The following are typical situations that require Subnet Connection Rules:
l
Point-to-point or point-to-multipoint connections between interfaces within subnets that have a prefix
length ranging from 28-31.
l
IPv4 tunnel or other virtual connections between interfaces within subnets that have a prefix length
ranging from 28-31.
NNMi uses Subnet Connection Rules to detect connections between interfaces associated with IPv4
addresses that do not respond to Layer 2 Discovery protocols (see the list of Topology Source protocols in
Layer 2 Connection Form). Subnet Connection Rules take priority over the Layer 2 Discovery protocol
results. For special cases, you can override a Subnet Connection Rule by using the Connection Editor
command line tool, see the nnmconnedit.ovpl Reference Page for more information.
When Spiral Discovery detects a subnet, NNMi uses the matching Subnet Connection Rule to request
information about all possible IPv4 addresses (potentially detecting previously undiscovered IPv4
addresses). NNMi checks the Excluded IP Addresses list. Any addresses in the list are dropped (for
details, see "Filters to Exclude Certain IP Addresses from Discovery" (on page 120)). Then NNMi creates
connections among any interfaces associated with any newly discovered IPv4 addresses.
To configure Subnet Connection Rules:
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Subnet Connection Rule form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
c. Select the Subnet Connection Rules tab.
Page 150 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
d. Do one of the following:
o To establish a rule, click the
o To edit a rule, click the
New icon, and continue.
Open icon in the row representing the configuration you want to
edit, and continue.
o To delete a rule, select a row, and click the
Delete icon.
3. Provide the required basic settings (see Basics table).
4. Provide the Subnet Connection behavior settings for this rule (see Details table).
5. Click
Save and Close to return to the Discovery Configuration form.
6. Click
Save and Close to apply the configuration. Spiral Discovery implements your changes
during the next regularly scheduled discovery interval. If more than two nodes are connected using
this rule, NNMi uses the following icon to indicate this special connection on maps (see example in
"Subnet Connection Rules" (on page 121)):
If you double-click the icon, the Layer 2 Connection form displays and the Topology Source value is
SUBNETCONNECTION.
Basics for this Subnet Connection Rule
Task
How
Name
Type a meaningful name for this Subnet Connection Rule. Alpha-numeric and special
characters (~ ! @ # $ % ^ & * ( ) _+) are allowed. No spaces are allowed.
Note: This name is prepended to the Layer 2 connection name (when you request Quick View
information about the connection on the Layer 2 Neighbor View map). If a subnet
matches more than one rule, NNMi randomly chooses from among the matching rules.
Enable
If enabled , NNMi uses the Subnet Connection Rule to create connections between
interfaces associated with the IPv4 addresses within the specified subnets.
If disabled
Page 151 of 1087
, NNMi ignores the Subnet Connection Rule.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Details for this Subnet Connection Rule
Task
How
Minimum
IPv4 Prefix
Length
Specify the minimum prefix length (subnet mask length) for the subnet where you want
Spiral Discovery to create Layer 2 connections. Spiral Discovery creates connections
between interfaces associated with IPv4 addresses that have subnet prefix lengths equal
to or greater than the specified value and meet the other specified criteria.
Valid Minimum IPv4 Prefix Length Values
Number of Usable IPv4 Addresses
28
14 (16-2=14)*
29
6 (8-2=6)*
30
2 (4-2=2)*
31
2
* Two IPv4 addresses are reserved in each subnet. The first IPv4 address is used for the
network itself and the last IPv4 address is reserved for broadcast.
ifType
Optional. Use this Interface MIB variable as an additional filter to identify the types of
interfaces to include when creating the subnet connections. For example, if you want
connections only between frameRelay interfaces, select frameRelay as the ifType.
ifName
Optional. Use this Interface MIB variable as an additional filter to identify the interfaces to
include when creating the subnet connections. This attribute is useful if you have a
naming convention that is used to identify a set of interfaces. For example, lan0.
Maximum 255 characters. The following wildcard characters are allowed: asterisk (*)
represents any string, and question mark (?) represents a single character.
ifDescription
Optional. Use this Interface MIB variable as an additional filter to identify the interfaces to
include when creating the subnet connections. For example, you might want to select a
particular set of interfaces that have the same vendor description.
Maximum 255 characters. The following wildcard characters are allowed: asterisk (*)
represents any string, and question mark (?) represents a single character.
ifAlias
Optional. Use this Interface MIB variable as an additional filter to identify the interfaces to
include when creating the subnet connections. This attribute is useful if you have an alias
naming convention that is used to identify a set of interfaces. For example, Connection
to remote store in Hawaii.
Maximum 255 characters. The following wildcard characters are allowed: asterisk (*)
represents any string, and question mark (?) represents a single character.
Related Topics
Intrepret Root Cause Messages
Subnet Connection Rules Provided by NNMi
The NNMi Subnet Connection Rules work only with IPv4 subnets.
NNMi provides the Subnet Connection Rules described in the following table (for more information, see
"Subnet Connection Rules" (on page 121)).
Page 152 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
The Small Subnets Rule ensures that NNMi detects IPv4 addresses within subnets of this size, regardless
of the interface type. The remaining Subnet Connection Rules create connections based on interface type
and the specified subnet size.
Tip: See IfTypes (Interface Types) Form for more information about interface types.
To create new Subnet Connection Rules (or modify the ones provided), see "Configure Subnet
Connection Rules" (on page 150).
Subnet Connection Rules Provided by NNMi
Rule Name
Minimum IPv4 Prefix Length
(Subnet Mask Length)
Interface Type (#)
Asynchronous Transfer Mode
28
atm (37)
Digital Signal 0
28
ds0 (81)
Digital Signal 1
28
ds1 (18)
Digital Signal 3
28
ds3 (30)
Digital Subscriber Loop over ISDN
28
idsl (154)
Frame Relay Interfaces
28
frameRelay (32)
Integrated Services Digital Network
28
isdn (63)
Multiprotocol Label Switching
28
mpls (166)
Point to Point
28
ppp (23)
Small Subnets
30
Serial Line Internet Protocol
28
slip (28)
Serial Point to Point
28
propPointToPointSerial (22)
Synchronous Optical Networking
28
sonnet (39)
Configure an Excluded IP Addresses Filter
Sometimes there are IP addresses or ranges of IP addresses in your environment that you do not want
NNMi to discover or monitor. For details and examples, see "Filters to Exclude Certain IP Addresses from
Discovery" (on page 120).
Tip: If you have a large number of IP addresses that you want to exclude from Spiral Discovery, see the
nnmdiscocfg.ovpl Reference Page.
To excluded specific IP addresses from the discovery process:
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Excluded IP Address form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
c. Select the Excluded IP Addresses tab.
d. Do one of the following:
Page 153 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
o To exclude an address or range of addresses from Spiral Discovery, click the
New
icon, and continue.
o To edit an excluded address setting, click the
Open icon in the row representing the
configuration you want to edit, and continue.
o To delete an excluded address setting, select a row, and click the
Delete icon.
3. To specify a range of IP addresses for this Auto-Discovery Rule, use one of the following. Pick one
address notation style, combinations of wildcards and CIDR notation are not allowed within one
address range. You can provide multiple address range settings:
n
IPv4 address wildcard notation.
An IPv4 Address range is a modified dotted-notation where each octet is one of the following:
o A specific octet value between 0 and 255
o A low-high range specification for the octet value (for example, "112-119")
o An asterisk (*) wildcard character which is equivalent to the range expression "0-255"
Note: The following two IPv4 addresses are considered invalid: 0.0.0.0 and 127.0.0.0
Examples of valid IPv4 address wildcards include:
10.1.1.*
10.*.*.*
10.1.1.1-99
10.10.50-55.*
10.22.*.4
10.1-9.1-9.1-9
n
IPv4 Classless Inter-Domain Routing (CIDR) notation.
The CIDR notation specifies the number of consecutive bits in the IPv4 address that must match.
For example, 10.2.120.0/21
Note: NNMi does not support CIDR subnet mask notation such as,
10.2.120.0/255.255.248.0
Example IPv4 Prefix Length Values
Number of Usable IPv4 Addresses
28
14 (16-2=14)*
29
6 (8-2=6)*
30
2 (4-2=2)*
31
2
* Two IPv4 addresses are reserved in each subnet. The first IPv4 address is used for the network
itself and the last IPv4 address is reserved for broadcast.
n
IPv6 address wildcard notation
Separate each 16-bit value of the IPv6 address with a colon. The 16-bit value can be any of the
following:
Page 154 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
o A specific hexadecimal value between 0 and FFFF (case insensitive).
o A low-high range specification of the hexadecimal value (for example, 1-1fe).
o An asterisk (*) wildcard character (equivalent to the range expression 0-ffff).
Note: The standard IPv6 short-hand notation (::) is allowed to express one or more 16-bit
elements of zero (0) values. However, the mixed IPv6/IPv4 dot-notation (for example,
2001:d88::1.2.3.4) is not allowed as an IPv6 address range.
Valid examples of ranges in modified IPv6 address notation include the following:
2001:D88:0:A00-AFF:*:*:*:*
2001:D88:1:*:*:*:*:*
2001:D88:2:0:a07:ffff:0a01:3200-37ff
n
IPv6 Classless Inter-Domain Routing (CIDR) notation
The CIDR notation specifies the number of consecutive bits in the IPv6 address that must match.
1080:0:a00::/44 (equivalent to modified IPv6 address notation 1080:0:a00a0f:*:*:*:*:*)
For example, valid IPv6 address ranges in CIDR notation include the following:
2001:d88:0:a00::/56 (equivalent to modified IPv6 address notation 2001:D88:0:A00AFF:*:*:*:*)
2001:d88:1::/48 (equivalent to modified IPv6 address notation 2001:D88:1:*:*:*:*:*)
4. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval. To apply the changes immediately, use Actions → Configuration Poll.
See Using Actions to Perform Tasks for more information.
Configure an Excluded Interfaces Filter
Sometimes there are certain types of interfaces in your environment that you do not want NNMi to discover
or monitor. For details and examples, see "Filters to Exclude Certain Interfaces from Discovery" (on page
120).
To excluded specific types of interfaces from the discovery process:
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Excluded Interfaces tab.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
c. Select the Excluded Interfaces tab.
3. Do one of the following:
n
To select an Interface Group to filter certain interfaces out of Spiral Discovery, click the
icon, and continue.
n
To edit an excluded interfaces setting, click the
configuration you want to edit, and continue.
n
To delete an excluded interfaces setting, select a row, and click the
Page 155 of 1087
Open icon in the row representing the
Delete icon.
New
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
n
To refresh the list of excluded interface settings, click the
n
To open the excluded interfaces settings list in a new window, click the
4. In the Interface Filter form, click the
down menu:
n
n
n
n
Refresh icon.
New Window icon.
Lookup icon and select one of the options from the drop-
Quick View to display summary information for the currently selected Interface Group.
Quick Find to view and select from the list of all existing Interface Groups (for more information
see "Use the Quick Find Window" (on page 28)).
Open to display the details of the currently selected Interface Group.
New to create a new Interface Group (see "Create Interface Groups" (on page 195) for more
information).
5. Click
Save and Close. Spiral Discovery implements your changes during the next regularly
scheduled discovery interval. To apply the changes immediately, use Actions → Configuration Poll.
See Using Actions to Perform Tasks for more information.
Specify Discovery Seeds: Initial Routers or Specific Nodes to be Discovered
Note: Discovery seeds are optional. Before you start this task, "Determine Your Approach to Discovery" (on
page 126) and complete the prerequisites ("Prerequisites for Discovery" (on page 123)).
Nodes specified as discovery seeds are always discovered and added to the topology database. As soon
as you enter one or more optional discovery seeds, discovery begins.
If you create Auto-Discovery Rules, NNMi uses neighbor information gathered from each discovery seed to
extend discovery. See "Discovery Seeds (as a starting point)" (on page 118) for more information. NNMi
can also use Ping Sweep (instead of or in addition to discovery seeds) to gather neighbor information. See
"Ping Sweep (as a starting point)" (on page 118). Note that with NNMi Advanced, Ping Sweep works only
with IPv4 addresses, not IPv6 addresses.
If you want Spiral Discovery to automatically find devices on your network, before you begin adding
discovery seeds:
l
Configure at least one Auto-Discovery Rule. See "Configure Auto-Discovery Rules" (on page 139).
l
Configure any number of Auto-Discovery Rules to maintain fine control over the scope of Spiral
Discovery.
A discovery seed is a hostname (not case-sensitive) or IP address. Consider devices with the largest
neighbor data in your network environment. For example, a good choice would be a core router connected
to a network you want to discover.
If you change your mind and delete a discovery seed from Discovery Configuration, the corresponding
node is not deleted from the topology database. See "Delete Nodes" (on page 170) for information about
removing the entire node record from the topology database.
To configure discovery seeds do one or more of the following:
l
"In the Console, Configure Discovery Seeds " (on page 157)
l
"With a Seed File, Add Multiple Discovery Seeds" (on page 160)
l
"From the Command Line, Add Discovery Seeds" (on page 162)
Related Topics
Page 156 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
"Discovery Seed Results" (on page 165)
"Delete Discovery Seeds" (on page 171)
In the Console, Configure Discovery Seeds
There are many ways to provide discovery seeds. Discovery seeds are optional. See "Specify Discovery
Seeds: Initial Routers or Specific Nodes to be Discovered" (on page 156)for more information.
To add an optional discovery seed using the console:
1. Complete all prerequisites. See "Prerequisites for Discovery" (on page 123), .
2. Navigate to the Discovery Seeds form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
c. Locate the Discovery Seeds tab.
d. Do one of the following:
o To add a discovery seed, click the
New icon.
o To edit a discovery seed, click the
Open icon in the row representing the discovery
seed you want to edit.
o To delete a discovery seed, select a row, and click the
Delete icon (see "Delete
Discovery Seeds" (on page 171) and "Delete Nodes" (on page 170) for more information).
3. Provide appropriate information (see table).
NNMi uses information gathered from Routers to establish subnet membership for Layer 3
connections. Make sure that important Routers in your network environment are SNMP enabled.
NNMi uses either of the following criteria to identify a Router:
n
Each Router responds with appropriate values for sysServices (1.3.6.1.2.1.1.7) and ipForwarding
(1.3.6.1.2.1.4.1). See RFC 1213-MIB for details.
n
Identify Routers with the Device Profile configuration settings for a particular device type.
You must provide the appropriate SNMP Community Strings to NNMi. See "Configuring
Communication Protocol" (on page 66).
4. Click
Save and Close to return to the Discovery Configuration form.
Tip: Click the
Save and New icon to continue to adding discovery seeds.
5. Click
Save and Close. As soon as you enter one or more optional discovery seeds, discovery
begins.
Page 157 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Discovery Seed Definition
Attribute
Definition
Hostname
/ IP
Address
Note: NNMi does not validate your entry when you use this method to add discovery seeds.
Use the nnmloadseeds.ovpl command to validate your discovery seed entries.
To identify the node, enter one of the following:
l
Fully-qualified hostname of the discovery seed (not case-sensitive)
l
IP address of the discovery seed, specify a physical address
When providing IPv4 addresses as discovery seeds, click here for more information.
The following IPv4 addresses are considered invalid:
l
255.255.255.255
l
IP addresses that begin or end with 0 (zero)
When providing IPv6 addresses as discovery seeds, use IPv6 notation as defined in RFC
2373. click here for more information.
l
16-byte (128-bit) address, composed of eight groups of 2-byte (16-bit) hex values
separated by colons (XXXX:XXXX: XXXX:XXXX: XXXX:XXXX: XXXX:XXXX)
l
Uppercase and lowercase (A-F/a-f) allowed for the hex digits.
Note: NNMi displays IPv6 addresses as all lowercase.
l
Optional. Omit leading zeros in each 2-byte hex value.
l
:: means a single contiguous sequence of all zero 2-byte hex values. However, :: is
allowed only one time per address. For example, the following three IPv6 address
notations are equivalent:
1080:0000:0000:0000:0008:0800:200C:417A
1080:0:0:0:8:800:200c:417a
1080::8:800:200C:417a
l
For the right-most 32-bits, IPv4 dotted-decimal notation can replace the pair of 2-byte
hex values. For example, the following two IPv6 address notations are equivalent:
1080::5efe:10.7.150.201
1080::5efe:a07:96c9
Page 158 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Attribute
Definition
Types of IPv6 Addresses
IPv6 Address Range
Explanation
2000:: to
3fff:ffff:ffff:ffff:ffff:ffff:ffff
global unicast address 1
fd00:: to
fdff:ffff:ffff:ffff:ffff:ffff:ffff
unique local address 2
fe80::XXXX:XXXX:XXXX:XXXX
link-local address 3 (do not use as a
seed)
ff00:: to
ffff:ffff:ffff:ffff:ffff:ffff:ffff
multicast address 4 (do not use as a
seed)
Discovery
Seed
Results
An automatically generated value. The most recent discovery status for this discovery seed.
See "Discovery Seed Results" (on page 165) for details.
Last
Modified
The date and time of the last change in Discovery Seed Results.
1(2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) A publically routable IPv6 unicast address, used for communication
between nodes anywhere on the internet. The first part of the address is a global routing prefix in the
2000::/3 address space for your organization (assigned by the Internet Service Providers). The complete
host address may either be manually configured or automatically assigned using IPv6 auto-configuration
and neighbor discovery.
2(fd00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) A privately routable IPv6 unicast address used only for communication
between nodes within your organization. The unique local addresses cannot be routed to the public
internet. Comprised of a routing prefix in the fd00:/8 address spaces, assigned locally by your
organization. And the full host address may be manually configured or automatically assigned using IPv6
auto-configuration and neighbor discovery.
3A non-routable IPv6 unicast address only used for communication with other nodes on the same link
(LAN or VLAN). Link local addresses cannot be used for communication that must be forwarded through a
router. IPv6 auto-configuration automatically assigns a unique link local address in the fe80::/10 address
space to each IPv6-enabled interface on a system.
4Used to identify a group of hosts joined into a group, IPv4 multicast addresses are in the range 224.0.0.0
to 239.255.255.255 and IPv6 multicast addresses have the prefix ff00::/8
Page 159 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Attribute
Definition
Notes
Provide any additional information about this discovery seed that would be useful to you or
your team.
Type a maximum of 1024 characters. Alpha-numeric, spaces, and special characters (~ ! @
# $ % ^ & * ( ) _+) are allowed.
With a Seed File, Add Multiple Discovery Seeds
There are many ways to provide discovery seeds. Discovery seeds are optional. See "Specify Discovery
Seeds: Initial Routers or Specific Nodes to be Discovered" (on page 156)for more information.
Use a seed file to simultaneously add large numbers of discovery seeds. Your seed file contains one line
for each discovery seed. For example:
12.2.111.104# cisco5500
12.2.112.268# cisco6509
12.2.119.205# cisco5500
Note: Any comments included after the # in a seed file become Notes attribute values for the discovery
seeds.
To identify a discovery seed, enter one of the following:
l
Fully-qualified hostname of the discovery seed (not case-sensitive)
l
IP address of the discovery seed, specify a physical address
When providing IPv4 addresses as discovery seeds, click here for more information.
The following IPv4 addresses are considered invalid:
l
255.255.255.255
l
IP addresses that begin or end with 0 (zero)
When providing IPv6 addresses as discovery seeds, use IPv6 notation as defined in RFC 2373. click here
for more information.
l
16-byte (128-bit) address, composed of eight groups of 2-byte (16-bit) hex values separated by colons
(XXXX:XXXX: XXXX:XXXX: XXXX:XXXX: XXXX:XXXX)
l
Uppercase and lowercase (A-F/a-f) allowed for the hex digits.
Note: NNMi displays IPv6 addresses as all lowercase.
l
Optional. Omit leading zeros in each 2-byte hex value.
l
:: means a single contiguous sequence of all zero 2-byte hex values. However, :: is allowed only
one time per address. For example, the following three IPv6 address notations are equivalent:
1080:0000:0000:0000:0008:0800:200C:417A
1080:0:0:0:8:800:200c:417a
1080::8:800:200C:417a
l
For the right-most 32-bits, IPv4 dotted-decimal notation can replace the pair of 2-byte hex values. For
example, the following two IPv6 address notations are equivalent:
1080::5efe:10.7.150.201
1080::5efe:a07:96c9
Page 160 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Types of IPv6 Addresses
IPv6 Address Range
Explanation
2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff
global unicast address 1
fd00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff
unique local address 2
fe80::XXXX:XXXX:XXXX:XXXX
link-local address 3 (do not use as a seed)
ff00:: to ffff:ffff:ffff:ffff:ffff:ffff:ffff
multicast address 4 (do not use as a seed)
NNMi uses information gathered from Routers to establish subnet membership for Layer 3 connections.
Make sure that important Routers in your network environment are SNMP enabled.
NNMi uses either of the following criteria to identify a Router:
l
Each Router responds with appropriate values for sysServices (1.3.6.1.2.1.1.7) and ipForwarding
(1.3.6.1.2.1.4.1). See RFC 1213-MIB for details.
l
Identify Routers with the Device Profile configuration settings for a particular device type.
You must provide the appropriate SNMP Community Strings to NNMi. See "Configuring Communication
Protocol" (on page 66).
To create a seed file:
In a text editor, type each entry on a separate line in the following format:
<IP_address> or <hostname> #(optional comment to help identify the node)
l
<IP_address> = the IP address of the node
l
<hostname> = the DNS fully-qualified or short hostname (not case-sensitive) of the node
To add discovery seeds by loading a seed file:
Use the nnmloadseeds.ovpl command:
<path>/<file_name> = the name of the file that contains your discovery seeds
Windows:
%NnmInstallDir%\bin\nnmloadseeds.ovpl -f <path>\<file_name>
1(2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) A publically routable IPv6 unicast address, used for communication
between nodes anywhere on the internet. The first part of the address is a global routing prefix in the
2000::/3 address space for your organization (assigned by the Internet Service Providers). The complete
host address may either be manually configured or automatically assigned using IPv6 auto-configuration
and neighbor discovery.
2(fd00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) A privately routable IPv6 unicast address used only for communication
between nodes within your organization. The unique local addresses cannot be routed to the public
internet. Comprised of a routing prefix in the fd00:/8 address spaces, assigned locally by your
organization. And the full host address may be manually configured or automatically assigned using IPv6
auto-configuration and neighbor discovery.
3A non-routable IPv6 unicast address only used for communication with other nodes on the same link
(LAN or VLAN). Link local addresses cannot be used for communication that must be forwarded through a
router. IPv6 auto-configuration automatically assigns a unique link local address in the fe80::/10 address
space to each IPv6-enabled interface on a system.
4Used to identify a group of hosts joined into a group, IPv4 multicast addresses are in the range 224.0.0.0
to 239.255.255.255 and IPv6 multicast addresses have the prefix ff00::/8
Page 161 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
UNIX:
/opt/OV/bin/nnmloadseeds.ovpl -f <path>/<file_name>
A message displays, showing the number of added, invalid, and ignored discovery seeds. For example:
26 seeds added
0 seeds invalid
0 seeds duplicated
See the nnmloadseeds.ovpl Reference Page for more information.
Related Topics
"Discovery Seed Results" (on page 165)
"Delete Discovery Seeds" (on page 171)
From the Command Line, Add Discovery Seeds
There are many ways to provide discovery seeds. Discovery seeds are optional. See "Specify Discovery
Seeds: Initial Routers or Specific Nodes to be Discovered" (on page 156)for more information.
You can add optional discovery seeds using the nnmloadseeds.ovpl command:
<seed_list> = the discovery seed entries (fully-qualified DNS hostname, short DNS hostname, or IP
address)
Windows:
%NnmInstallDir%\bin\nnmloadseeds.ovpl -n <seed_list>
UNIX:
/opt/OV/bin/nnmloadseeds.ovpl -n <seed_list>
In the following example, the devices with a hostname of cisco4 and cisco5, and a device with the IP
address of 12.6.91.5 are added as discovery seeds.
nnmloadseeds.ovpl -n cisco4 cisco5 12.6.91.5
Note: Identify the discovery seed by either a DNS-resolvable hostname or an IP address.
When adding individual discovery seeds using the nnmloadseeds.ovpl command:
l
Fully-qualified hostname of the discovery seed (not case-sensitive)
l
IP address of the discovery seed, specify a physical address
When providing IPv4 addresses as discovery seeds, click here for more information.
The following IPv4 addresses are considered invalid:
l
255.255.255.255
l
IP addresses that begin or end with 0 (zero)
When providing IPv6 addresses as discovery seeds, use IPv6 notation as defined in RFC 2373. click here
for more information.
l
16-byte (128-bit) address, composed of eight groups of 2-byte (16-bit) hex values separated by colons
(XXXX:XXXX: XXXX:XXXX: XXXX:XXXX: XXXX:XXXX)
l
Uppercase and lowercase (A-F/a-f) allowed for the hex digits.
Page 162 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Note: NNMi displays IPv6 addresses as all lowercase.
l
Optional. Omit leading zeros in each 2-byte hex value.
l
:: means a single contiguous sequence of all zero 2-byte hex values. However, :: is allowed only
one time per address. For example, the following three IPv6 address notations are equivalent:
1080:0000:0000:0000:0008:0800:200C:417A
1080:0:0:0:8:800:200c:417a
1080::8:800:200C:417a
l
For the right-most 32-bits, IPv4 dotted-decimal notation can replace the pair of 2-byte hex values. For
example, the following two IPv6 address notations are equivalent:
1080::5efe:10.7.150.201
1080::5efe:a07:96c9
Types of IPv6 Addresses
IPv6 Address Range
Explanation
2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff
global unicast address 1
fd00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff
unique local address 2
fe80::XXXX:XXXX:XXXX:XXXX
link-local address 3 (do not use as a seed)
ff00:: to ffff:ffff:ffff:ffff:ffff:ffff:ffff
multicast address 4 (do not use as a seed)
Communicate any additional IP address requirements to your team to avoid unexpected discovery results.
NNMi uses information gathered from Routers to establish subnet membership for Layer 3 connections.
Make sure that important Routers in your network environment are SNMP enabled.
NNMi uses either of the following criteria to identify a Router:
l
Each Router responds with appropriate values for sysServices (1.3.6.1.2.1.1.7) and ipForwarding
(1.3.6.1.2.1.4.1). See RFC 1213-MIB for details.
l
Identify Routers with the Device Profile configuration settings for a particular device type.
You must provide the appropriate SNMP Community Strings to NNMi. See "Configuring Communication
Protocol" (on page 66).
Related Topics
1(2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) A publically routable IPv6 unicast address, used for communication
between nodes anywhere on the internet. The first part of the address is a global routing prefix in the
2000::/3 address space for your organization (assigned by the Internet Service Providers). The complete
host address may either be manually configured or automatically assigned using IPv6 auto-configuration
and neighbor discovery.
2(fd00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) A privately routable IPv6 unicast address used only for communication
between nodes within your organization. The unique local addresses cannot be routed to the public
internet. Comprised of a routing prefix in the fd00:/8 address spaces, assigned locally by your
organization. And the full host address may be manually configured or automatically assigned using IPv6
auto-configuration and neighbor discovery.
3A non-routable IPv6 unicast address only used for communication with other nodes on the same link
(LAN or VLAN). Link local addresses cannot be used for communication that must be forwarded through a
router. IPv6 auto-configuration automatically assigns a unique link local address in the fe80::/10 address
space to each IPv6-enabled interface on a system.
4Used to identify a group of hosts joined into a group, IPv4 multicast addresses are in the range 224.0.0.0
to 239.255.255.255 and IPv6 multicast addresses have the prefix ff00::/8
Page 163 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
"Discovery Seed Results" (on page 165)
"Delete Discovery Seeds" (on page 171)
Examine Discovery Results
When verifying discovery, you can do any of the following tasks:
l
"Check Initial Progress of Discovery" (on page 164)
l
"Verify Success of Discovery Seeds" (on page 165)
l
"Examine Discovery Inventory " (on page 167)
l
"Examine Layer 2 Discovery Results" (on page 168)
l
"Examine Layer 3 Discovery Results" (on page 168)
Related Topics
"Node Discovery State Check" (on page 164)
"Discovery Seed Results" (on page 165)
Check Initial Progress of Discovery
During initial NNMi discovery of your network, you can check Spiral Discovery's progress in the following
ways:
l
Click Help → System Information (for more information see Displaying NNMi System Information):
n
Navigate to the Database tab to find the real-time list of discovery's progress.
n
Navigate to the State Poller tab to see a report of the health of the State Poller Service.
l
To see state of discovery for a node, see "Node Discovery State Check" (on page 164).
l
NNMi administrators can use the command line on any NNMi management server to generate a report
about NNMi health. See the nnmhealth.ovpl Reference Page for more information.
Check this several times during a one hour period. The numbers in the Nodes, SNMP agents, Interfaces,
IP addresses, and Layer 2 Connections fields stabilize when initial discovery is complete
Note: If you configure one or more Auto-Discovery Rules and you get unexpected results, check your
ordering numbers. See "Configure Auto-Discovery Rules" (on page 139) for more information.
Node Discovery State Check
You can verify the current discovery state for a node.
To see the current Discovery State for a node:
1. Navigate to a Node form.
a. From the workspaces navigation panel, select the workspace of interest. For example,
Inventory.
b. Select the node view of interest. For example Nodes.
c. Click the
Open icon in the row representing the configuration you want to see.
Page 164 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
2. Locate the Discovery State attribute (in the Discovery section on the left side of the form).
Possible values include:
n
Newly Created – Indicates the node and its IP addresses are in the NNMi database, but further
information needs to be collected before state and status are determined.
n
Discovery Completed – Indicates that discovery gathered all required information for the node.
n
Rediscovery in Process – Indicates discovery is updating the information collected for the node.
Verify Success of Discovery Seeds
The discovery seeds provide the starting point for discovery.
To verify that each discovery seed was successfully discovered:
1. Navigate to the Discovery Configuration form.
n
From the workspace navigation panel, select the Configuration workspace.
n
Select the Discovery Configuration.
2. Locate the Discovery Seeds tab.
3. Check the value in the Discovery Seed Results column on each row of the table. A value of Node
Created indicates the successful discovery of each discovery seed. See "Discovery Seed Results"
(on page 165) for the meaning of other values and how to correct discovery problems.
Discovery Seed Results
When you add a discovery seed, the Discovery Service immediately tries to discover it (without waiting
until the next regularly scheduled discovery interval). If discovery is not successful, NNMi tries again 10
minutes later, and continues trying. The time between each try is doubled until it reaches 1 week or equals
your current discovery interval.
To see the current discovery results for each specified discovery seed:
1. Navigate to the Discovery Configuration form
n
From the workspace navigation panel, select the Configuration workspace.
n
Select Discovery Configuration.
2. Locate the Discovery Seeds tab. The table lists each discovery seed and the result that NNMi
gathered when contacting the discovery seed.
3. Check the value in the Discovery Seed Results column on each row of the table.
Discovery Seed Results Values
Discovery
Results
Description
New seed
You just entered a new discovery seed. When discovery begins, Discovery Results
changes to "In progress". If the "New seed" value does not change, check to see if the
Discovery Service needs to be restarted, see "Verify that NNMi Services are Running"
(on page 47).
In progress
Discovery is in progress.
Page 165 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Discovery
Results
Description
Node created
The discovery seed is successfully discovered and a new Node is created in the
database.
Node created
(non-SNMP
device)
The hostname or IP address you provided is a non-SNMP device. The Node was
discovered and added to the database, but no SNMP information is available because
no SNMP agent responded.
If this result is unexpected, the device might currently be down. Initiate an on-demand
discovery poll using Actions → Configuration Poll, click here for more information. Or
try the following:
Check whether the IP address is accessible
1. Type the following command to verify that the address is accessible:
ping <nodename>
Check the Access Control List
1. Access the Node, and open the Access Control List (ACL).
2. Verify that the NNMi management server address is in the list.
Ensure that SNMP is working
1. Use the nnmsnmpwalk.ovpl command. Type the following to verify that the
address has an SNMP agent. Supply one specific MIB variable to limit network
traffic to one object rather than requesting all possible SNMP values. For
example, use the VendorID prefix with SNMPv1 or SNMPv2c:
nnmsnmpwalk –c <communityString> <nodename or IP address>
<VendorID>
2. If the nnmsnmpwalk.ovpl fails:
a. Use telnet to check the device's SNMP configuration to verify that SNMP is
enabled.
b. Verify that the address of the NNMi management server is listed in the
SNMP Agent's Access list.
Check your communication configuration
1. Verify that SNMP communication is enabled for this device: "Configuring
Communication Protocol" (on page 66).
2. Verify that the device has a properly configured SNMPv1 or SNMPv2c read
community string, or that the device has a properly configured SNMPv3 USM
security setting.
Note: NNMi makes one attempt to contact each discovery seed. After you correct the
problem that caused NNMi to specify the seed as a non-SNMP device, NNMi
updates the Node record during the next discovery cycle. However, this
Discovery Results entry does not change, but everything is working properly.
Node not
created (DNS
name
resolution
failed)
The Domain Name System (DNS) protocol could not match the hostname you provided
for this discovery seed with a valid IP address.
Page 166 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Discovery
Results
Description
Node not
created
(duplicate
seed)
The address or hostname you provided is a Node that already exists in the database.
Node not
created (IPv6
disabled)
The address you provided is an IPv6 address. NNMi Advanced is required, and the
IPv6 feature must be enabled.
Node not
created (IPv6
link local
address is
invalid seed)
The address you provided is an IPv6 link local address, or the hostname you provided
has only one address (an IPv6 link local address). Link local addresses cannot be
used as seeds.
Node not
created
(license
exceeded)
Discovery rejected this discovery seed because the number of devices previously
discovered reached your licensed capacity limit. See "Extend a Licensed Capacity" (on
page 1013).
Failed
Contact with this discovery seed failed due to an internal NNMi error. The problem
might be related to discovery or to a system wide issue, such as running out of memory
or having trouble with database access. Check the discovery log file (see "Verify that
NNMi Services are Running" (on page 47)):
The hostname you provided has only IPv6 addresses. NNMi Advanced is required, and
the IPv6 feature must be enabled.
l
Windows:
%NnmDataDir%\log\nnm\nnm.0.0.log
l
UNIX:
/var/opt/OV/log/nnm/nnm.0.0.log
Related Topics:
"Specify Discovery Seeds: Initial Routers or Specific Nodes to be Discovered" (on page 156)
Examine Discovery Inventory
The best method for examining your discovered inventory depends on how you configure discovery.
To examine your Discovery Inventory:
1. In the Workspace navigation panel, open the Inventory workspace.
2. Select the IP Addresses view.
3. Optional. Verify that each IP address that you identified as a discovery seed is listed.
4. Verify that the IP addresses you expect to see are visible (based on any address ranges where
Discover Included Nodes is enabled or disabled).
5. To check on the current discovery state for a particular node, see "Node Discovery State Check" (on
page 164).
Note: If you configure one or more Auto-Discovery Rules and you get unexpected results, check your
ordering numbers. See "Configure Auto-Discovery Rules" (on page 139) for more information.
Page 167 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Related Topics
Using the IP Addresses View
Using the Nodes View
Examine Layer 2 Discovery Results
Layer 2 represents your network's physical connections and LAN switch traffic routes.
To examine Layer 2 inventory and connectivity results:
1. In the Workspace navigation panel, open the Inventory workspace.
2. Select the Nodes view.
3. Select the node of interest.
4. Select Actions → Layer 2 Neighbor View.
5. Use the Number of Hops field to expand the area shown on the map.
6. Examine your network connectivity to ensure it is as expected. See "Add or Delete a Layer 2
Connection" (on page 174) if changes are required.
Note: If you configure one or more Auto-Discovery Rules and you get unexpected results, check your
ordering numbers. See "Configure Auto-Discovery Rules" (on page 139) for more information.
To examine VLAN results:
1. In the Workspace navigation panel, open the Inventory workspace.
2. Select the VLANs view.
3. Select the VLAN of interest.
4. Click
Open to open the VLAN form.
5. Verify that the list includes all nodes and ports assigned to this VLAN.
Note: If you configure one or more Auto-Discovery Rules and you get unexpected results, check your
ordering numbers. See "Configure Auto-Discovery Rules" (on page 139) for more information.
Related Topics
Using the Layer 2 Neighbor View
Using the Layer 3 Neighbor View
Examine Layer 3 Discovery Results
Layer 3 represents your network's router traffic.
To examine Layer 3 inventory results:
1. In the Workspace navigation panel, open the Inventory workspace.
2. Select the Nodes view.
3. Select the router of interest.
4. Select Actions → Layer 3 Neighbor View.
5. Use the Number of Hops field to expand the area shown on the map.
Page 168 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
6. Examine your network connectivity to ensure it is as expected. If changes are required, try the
following:
n
Use Actions → Configuration Poll. See Using Actions to Perform Tasks for more information.
n
Manually add or delete the connection. See "Add or Delete a Layer 2 Connection" (on page 174)
.
n
Verify that the addresses on each end of the connection are not listed in the Excluded IP Address
filter. See "Configure an Excluded IP Addresses Filter" (on page 153).
Note: If you configure one or more Auto-Discovery Rules and you get unexpected results, check your
ordering number for each rule. See "Configure Auto-Discovery Rules" (on page 139) for more
information.
Related Topics
Using the Layer 2 Neighbor View
Using the Layer 3 Neighbor View
Keep Your Topology Accurate
With NNMi, discovery is ongoing. After initial discovery, NNMi checks periodically to ensure that the maps
accurately reflect the state of your network. NNMi also updates the database to reflect any changes. See
About Map Symbols for an explanation of symbols on the maps.
By default, NNMi uses the following methods to keep the maps accurate:
Spiral Discovery. NNMi uses neighbor information gathered from various devices on your network to
discover all devices connected to your network.
Scheduled Rediscovery. Discovery occurs automatically at the interval you define. See"Adjust the
Rediscovery Interval" (on page 137) for more information about setting the discovery schedule.
Delete Nodes. As an administrator, you can delete any nodes that you no longer use, or delete nodes to
force NNMi to rediscover them. See "Delete Nodes" (on page 170)for more information.
Tip: NNMi also monitors the health of the discovered devices. The health is indicated by the color of the
background shape of each device icon on the map. See "Status Colors" for more information. For
information about how health monitoring works, see "About the State Poller" (on page 213) and
"Monitoring Network Health" (on page 213).
Add or Delete Discovery Seeds. As an administrator, you can delete any Discovery Seeds that you no
longer need. See "Delete Discovery Seeds" (on page 171) for more information.
Accurately Detect Interface Changes. If NNMi does not show an accurate list of interfaces in a particular
device, you may need to update the settings in the related Device Profile. See "Detect Interface Changes
(renumbering issues)" (on page 172).
Add Connections that are not automatically discovered. There are two methods for adding connections:
l
Subnet Connection Rules are ideal for the following situations:
n
Point-to-point or point-to-multipoint connections between interfaces within subnets that have a
prefix length ranging from 28-31.
n
IPv4 tunnel or other virtual connections between interfaces within subnets that have a prefix length
ranging from 28-31.
Page 169 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
NNMi uses Subnet Connection Rules to detect connections between interfaces associated with IPv4
addresses that do not respond to Layer 2 Discovery protocols (see the list of Topology Source
protocols in Layer 2 Connection Form). Subnet Connection Rules take priority over the Layer 2
Discovery protocol results. For special cases, you can override a Subnet Connection Rule by using the
Connection Editor command line tool. See "Configure Subnet Connection Rules" (on page 150) for
more information.
l
Connection Editor (nnmconnedit.ovpl command line tool) If your network management domain
includes ATM, Frame Relay, or MPLS1 links between wide area networks (WANs), you may need to
use the connection editor to show the links in the Layer 2 Neighbor View maps within NNMi. For MPLS,
you can provide multiple connections between two nodes. See "Add or Delete a Layer 2 Connection"
(on page 174) and the nnmconnedit.ovpl Reference Page for more information.
Delete Connections. Use the Connection Editor (nnmconnedit.ovpl command line tool) to instruct NNMi to
ignore certain connections. See "Add or Delete a Layer 2 Connection" (on page 174) and the
nnmconnedit.ovpl Reference Page for more information
Delete Nodes
NNMi administrators can delete nodes from a table view, map view, or Node form. For example:
l
Remove any nodes that are no longer being used in the network.
l
When non-SNMP addresses that had the same DNS hostname are changed to have separate DNS
hostnames, NNMi must completely rediscover the non-SNMP nodes to correctly update the database
objects (node, interface, address, connection, and incidents).
To understand the results of deleting a Node, click here for more information.
l
NNMi cleans up the database by deleting the following objects:
n
Any objects representing things contained in the deleted Node (for example, all of that node's
interfaces and IP addresses).
n
Any related objects that are empty after deleting the Node (for example, subnets).
n
Any connections with only zero or one end points after deleting the Node.
l
The time required for NNMi to finish deleting depends on the number of objects or related objects
being deleted.
l
During future discovery cycles, if the deleted Node meets the criteria for an Auto-Discovery Rule and
appears in a monitored router's ARP cache, NNMi adds the Node back into the NNMi database during
the next discovery cycle. To prevent this, create an Excluded IP Addresses filter for the addresses (see
"Configure an Excluded IP Addresses Filter" (on page 153)).
l
During future monitoring cycles, NNMi polls only objects currently in the database.
l
Each Incident associated with the deleted Node is modified in the following ways, but not deleted from
the NNMi database:
n
The Status attribute changes to Closed.
n
The Correlation Notes indicate the deletion of the associated node, interface, or address.
n
The RCA State attribute changes to FALSE.
1Multiprotocol Label Switching
Page 170 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Note: Incidents generated from SNMP traps or NNM 6.x/7.x Events (received from the deleted Node)
appear in the Incident views, but remain unresolved.
l
If you are viewing a Node that has recently been deleted by another user, the deleted Node appears
as a transparent icon on the map until the map is refreshed using the
Refresh icon. After Refresh,
the deleted node is removed from the map. NNMi does not automatically refresh the connectivity or set
of nodes in a map view, except on the Network Overview map.
Note: If you delete a Node with many interfaces and VLANs, you may see an error message indicating that
the Node could not be deleted. This means the database was busy with discovery. Try again
between discovery cycles.
If a deleted Node is one of your seeds, delete that seed from the Discovery Seeds table as well. See
"Delete Discovery Seeds" (on page 171).
To delete one or more nodes (maximum 20 at one time):
1. Unmanage the nodes you want to delete.
a. In a table view, select the nodes of interest by selecting the
that represents each node you want to unmanage.
check box in the row or rows
b. Select Actions → Management Mode → Unmanage.
c. Wait until the Status=No Status for each of the following objects:
o Each Node to be deleted
o Each Node's Interfaces, IP Addresses, Cards, Ports, and VLAN Ports
2. Do one of the following:
n
Table views: select the object of interest by selecting the check box in the row or rows that
represents the objects of interest, and click the
Delete icon. Each selected node is deleted
from the NNMi database and removed from the current view.
n
Map views: click the map symbol representing the node you want to delete, and click File →
Delete Node. The node is deleted from the NNMi database and removed from the current view.
n
Node form: select File → Delete Node and in the confirmation dialog, click OK. The form is
automatically closed after NNMi deletes the Node.
Note: If the delete fails, use the nnmnodedelete.ovpl command. Wait for the command to complete.
To delete any number of nodes:
Use the nnmnodedelete.ovpl command. See the nnmnodedelete.ovpl Reference Page.
Related Topics
Using Table Views
Using Map Views
Delete Discovery Seeds
There are two ways to delete discovery seeds from the NNMi Discovery configuration and the NNMi
database.
Page 171 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Note: If you remove a Discovery Seed from Discovery Configuration, the corresponding node is not
deleted from the topology database. See "Delete Nodes" (on page 170) for information about
removing the entire node record from the topology database.
To delete seeds using the Discovery Configuration view:
1. Navigate to the Discovery Seeds tab in the Discovery Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Discovery Configuration.
c. Locate the Discovery Seeds tab.
2. To delete one or more discovery seeds, select any number of rows, and click the
3. Click
Delete icon.
Save and Close.
To delete any number of seeds at one time from the command line:
At the command line of the NNMi management server, type the nnmseeddelete.ovpl command.
Case-sensitive exactly as listed in the Discovery Seeds tab in the Discovery Configuration form, specify
the hostname or IP address.
If you do not want to enter an NNMi User Name attribute value and an NNMi Password attribute value at
the command line, you can use the nnmsetcmduserpw.ovpl command to specify the valid user name and
password (instead of -u and -p). The credentials set using the nnmsetcmduserpw.ovpl command are
valid for command execution by the same user. See "Set Up Command Line Access" (on page 273) for
more information.
nnmseeddelete.ovpl -seed <hostname/IP-address> -u <NNMiadminUserName> -p
<NNMiadminPassword>
Detect Interface Changes (renumbering issues)
Sometimes the hardware configuration of a device in your network changes (for example, adding a card
with 20 interfaces to a router). When someone installs or removes interfaces from a device in your network:
l
Some devices maintain a static list of MIB II IfIndex numbers. When interfaces are added, MIB II
IfIndex numbers are added to the end of the current list of interfaces contained in that device. When
interfaces are removed, the MIB II IfIndex numbers previously used by those interfaces are dropped
from the list.
l
Some devices reset all MIB II IfIndex numbers for the group of interfaces contained in that device
each time a change occurs. Each manufacturer has a different strategy for identifying each interface
and detecting when an existing interface is simply assigned to a different MIB-II IfIndex number or an
interface is removed.
The NNMi administrator chooses which strategy is used for each manufacture/model. NNMi can use any of
the following MIB-II objects to track the group of interfaces within a device. These MIB-II objects are known
as Interface Reindexing Types in the Device Profile form. See Device Profile Form for more information.
Interface Reindexing Types
Interface Reindexing Type
Description
ifAlias value
Compares the ifAlias value on the interface with the
discovered ifAlias value.
ifDescr value
Compares the ifDescr value on the interface with the
discovered ifDescr value.
Page 172 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Interface Reindexing Type
Description
ifIndex value
Detects when an ifIndex value no longer exists. This
setting does not detect interface renumbering.
Note: Use ifIndex only for
manufacturers/models that maintain a static
ifIndex list.
ifName value
Compares the ifName value on the interface with the
discovered ifName value.
Combination of ifDescr and ifName
values
Compares the ifDescr and ifName values on the
interface with the discovered ifDescr and ifName
values.
The NNMi State Poller uses the Interface Reindexing Types described above for those interfaces for which
SNMP Interface Polling is enabled. See"Configure Interface Monitoring" (on page 221) for more
information. The Interface Reindexing Type determines the Device Profile value that the State Poller
compares. If the value collected by the State Poller is different than the discovered value, State Poller stops
polling the node and requests that the node be rediscovered. After the node is rediscovered, the State
Poller starts to poll the node again.
If you know that hardware changes were made for interfaces in your network environment, but NNMi
does not accurately reflect those changes as they happen, do the following:
1. Identify the manufacturer and model of the device with an interface setup that changed. Check the
device's documentation to find out which MIB-II values are used to provide a positive identification for
each interface.
2. Navigate to the appropriate Device Profile form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Device Profiles view.
c. Click the Device Model column heading to sort the list by manufacturer's name.
d. Locate the group of that manufacturer's devices.
e. Click the
Open icon in the row representing the configuration you want to see.
3. Locate the Interface Reindexing Type attribute, and click the drop-down list to display the available
choices (see Interface Reindexing Type in the Device Profile Form help).
4. Select the appropriate MIB-II values for NNMi to use when determining whether an interface has
moved and been renumbered, an interface was recently added, or an interface was removed.
5. Click
Save and Close to return to the Device Profile view.
6. To verify that the problem is solved, do one of the following:
n
For immediate results, navigate to a Node view and select one of the problem devices.
Click Actions → Configuration Poll to instruct NNMi to rediscover the information about
interfaces in that device.
Open the Node form for the device and verify that the list interfaces is correct.
Page 173 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
n
NNMi updates interface information for all matching manufacture/model devices in your network
environment the next regularly scheduled Discovery or Monitoring cycles.
Add or Delete a Layer 2 Connection
Tip: If your network management domain includes ATM, Frame Relay, or Multi-Protocol Label Switching
(MPLS) links between wide area networks (WANs), you may need to use the connection editor to show
the links in the Layer 2 Neighbor View maps within NNMi. For MPLS, you can provide multiple
connections between two nodes.
Use the NNMi nnmconnedit.ovpl command to add or delete connection data.
The nnmconnedit.ovpl command is used to generate a template XML file (shown in the following
example). For each connection to be added or deleted, you provide information about the node and
interface at both ends of the connection. Multiple <connection> elements are allowed within the template
XML file.
<connectionedits>
<connection>
<operation>add or delete</operation>
<node>node Name, Hostname or management IP address</node>
<interface>ifName, ifAlias, ifDescr or ifIndex</interface>
<node>node Name, Hostname, or management IP address</node>
<interface>ifName, ifAlias, ifDescr or ifIndex</interface>
</connection>
</connectionedits>
Required Layer 2 Connection Attributes in the Connection Editor File
Attribute
Description
operation
Specify whether the connection is to be added or deleted.
node
Identify the node using any of the following case-sensitive values:
l
node Name
l
Hostname (case-sensitive)
NNMi follows a set of rules to dynamically generate the value stored in the NNMi
database for each Node's Hostname. Click here for details.
Note: The actual Hostname might be converted to all uppercase or all lowercase before it
is added to the NNMi database (depending on how the NNMi administrator
Page 174 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Attribute
Description
configured settings in the nms-topology.properties file). See the information
about the nms-topology.properties file in the HP Network Node Manager i
Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals.
n
If the Node supports SNMP, NNMi requests the Hostname using the IP Address of the
associated SNMP agent (the Management Address attribute value on the Node form).
If the NNMi administrator chooses
Communication Configuration:
Enable SNMP Address Rediscovery in the
o If the SNMP Agent does not respond, NNMi checks for another Management
Address to request the Hostname, and the Hostname could change.
o If the SNMP Agent associated with the node changes, the Management Address
and Hostname could change.
If the NNMi administrator disables
Communication Configuration:
Enable SNMP Address Rediscovery in the
o If the SNMP Agent does not respond, NNMi uses the previously gathered
Management Address attribute value to request the Hostname.
o If the SNMP Agent associated with the node changes, NNMi uses the previously
gathered Management Address attribute value to request the Hostname.
n
l
If the Node does not support SNMP, no Management Address is available. NNMi
requests a Hostname starting with the lowest IP Address associated with the node (a
Discovery Seed value or an IP address value gathered from a neighboring device).
NNMi uses the first Hostname provided. The Hostname might change during a future
discovery cycle.
management IP address
NNMi follows a set of rules to determine which address is the best choice as the node's
Management Address. Click here for details.
Note: With NNMi Advanced, the NNMi administrator specifies whether NNMi prefers IPv4
or IPv6 addresses when selecting the Management Address. See the HP Network
Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals
a. NNMi ignores the following addresses when determining which Management
Address is most appropriate:
o Any address of an administratively-down interface.
Page 175 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Attribute
Description
o Any address that is virtual (HSRP/VRRP).
o Any IPv4 Anycast Rendezvous Point IP Address 1 or IPv6 Anycast address.
o Any address in the reserved loopback network range. IPv4 uses 127/24
(127.*.*.*) and IPv6 uses ::1.
o Any IPv6 link-local address 2.
b. NNMi prefers loopback interfaces for management communication.
o If a node has only one loopback address 3, and the associated SNMP agent
responds to NNMi, that address becomes the Management Address.
o If a node supports multiple loopback addresses, NNMi queries each loopback
addresses, starting with the lowest number. NNMi uses the loopback address
with the lowest number from which the SNMP agent responds (for example,
10.16.42.197 is a lower number than 10.16.197.42).
c. If no loopback address responds, NNMi queries the last-known Management
Address (if any).
d. If no response, NNMi queries up to 10 of any remaining IP addresses in the
node's IP address inventory, starting with the lowest number. NNMi uses the
address with the lowest number from which the SNMP agent responds.
e. If no response, NNMi might be configured to repeat the sequence using SNMPv1,
SNMPv2c, or SNMPv3 in the order specified by the NNMi administrator
(Communication Configurations SNMP Minimum Security Level settings).
f. When all else fails, NNMi retains the last known Management Address (if any)
and automatically changes the State of that SNMP Agent object to Critical.
This process is repeated during each Auto-Discovery cycle, and the Management
Address can change. For example, NNMi's inventory of addresses for the node expands,
or the current Management Address does not respond to SNMP queries due to network
problems or node reconfiguration. The NNMi administrator can prevent changes to the
management address using the Communication Configurations Enable SNMP Address
Rediscovery or Preferred Management Address setting.
1Rendezvous Point addresses are loopback addresses used for routers in multi-cast network
configurations.
2A non-routable IPv6 unicast address only used for communication with other nodes on the same link
(LAN or VLAN). Link local addresses cannot be used for communication that must be forwarded through a
router. IPv6 auto-configuration automatically assigns a unique link local address in the fe80::/10 address
space to each IPv6-enabled interface on a system.
3The address associated with the loopback interface. The loopback interface is a virtual interface on a
device that provides a route for internal communication. Many vendors provide a specially configured
loopback for management purposes. Exact details of how loopbacks are configured varies by vendor and
model. See each device's documentation for details. NNMi identifies these loopback addresses by using
IfType 24, softwareloopback from the IANA ifType-MIB.
Page 176 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
Attribute
Description
interface
Identify the interface using one or more of the following (MIB-II) values:
l
ifName
l
ifAlias
l
ifDescr
l
ifIndex Note the following for ifIndex:
n
For interfaces in Non-SNMP nodes, always use the ifIndex value of 0 (zero).
n
For interfaces in SNMP nodes, choose other MIB-II values to identify the interface
because often automatic interface renumbering causes confusion.
To add or delete a connection:
1. For the devices at both ends of the connection, gather the data required to identify the device and
interface.
2. On the NNMi management server, at the command line, generate a connections template file using
either add to create an add.xml template file or delete to create a delete.xml template file.
In the following example, NNMi creates an add.xml file:
nnmconnedit.ovpl -t add
Note: If you specify add, NNMi creates the template file named add.xml. If you use delete, the
template file is named delete.xml.
3. Open the template file in a text editor and fill in the correct information for each node and interface.
4. On the NNMi management server, at the command line, load the new connection information into the
NNMi database:
nnmconnedit.ovpl -f <add|delete>.xml
For example, to load the add.xml template file, enter:
nnmconnedit.ovpl -f add.xml
5. Open the Layer 2 Neighbor View map and verify the connection changes.
The connections you establish are listed in the Layer 2 Connections view in the Inventory workspace. To
delete a connection, you must use the nnmconnedit.ovpl command (no Delete action is available in the
Layer 2 Connections view).
Start Discovery On-Demand
NNMi provides the nnmnoderediscover.ovpl command line tool for initiating discovery. This tool allows
NNMi administrators to do the following:
l
Run discovery of a subset of your network domain to get the most recent data without waiting for the
next-regularly schedules discovery cycle.
For example, to immediately add newly deployed critical devices to the NNMi database without waiting
for the next regularly-scheduled discovery cycle.
l
Run discovery of your entire network on demand or using an automation script.
l
Request updated discovery results from the Regional Managers in your network environment after
Page 177 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Discovering Your Network
restoring the Global Manager to a previous state.
(NNMi Advanced - Global Network Management feature) Any change to the Node's Management
Mode setting is immediately sent from a Regional Manager (NNMi management server) to the Global
Manager. (Changes to Management Mode for other objects are sent during the next Auto-Discovery
cycle on the Regional Manager.)
Note: This tool can help you synchronize the Global Manager if for some reason the original
information from the Regional Managers is lost from the Global Manager's database.
See nnmnoderediscover.ovpl for more details.
Page 178 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Creating Groups of Nodes or Interfaces
Groups of nodes or interfaces are used for a variety of purposes within NNMi. Use of these groups is
optional.
l
Use node and interface groups to create custom view filters that help your team quickly sift through
data in the NNMi views and identify the most important information. See Filter Views by Node or
Interface Group.
l
Special Actions are available for Node Groups and Interface Groups.
l
Use Node Groups and Interface Groups to specify monitoring configuration settings. See"Monitoring
Network Health" (on page 213). For example, configure a different health monitoring interval for each
group.
l
(NNMi Advanced - Global Network Management feature) On a Regional Manager, use Node Groups to
limit the amount of data available to Global Managers in your network environment. See "Regional
Manager: Create a Forwarding Filter (Limit the available Node information)" (on page 53) for more
information.
l
(NNM iSPI Performance) If you are using the HP Network Node Manager iSPI Performance for Metrics
Software or HP Network Node Manager iSPI Performance for Traffic Software software, control
performance monitoring and provide report filters by Node Group.
Once Node Groups or Interface Groups are defined, you can reuse them within any context (view filtering
and NNMi configuration settings) or you can configure them to be hidden from the view filter lists.
View Filter Possibilities
Available in NNMi views based on: Object Type
Filter
Node Groups
"Create Node Groups" (on page
179)
Interface Groups
"Create Interface Groups" (on page
195)
Incident
Node
Interface
IP
Address
x
x
x
x
x
x
Card
Node
Component
x
x
Create Node Groups
Node Groups are used for a variety of purposes in NNMi. See "Creating Groups of Nodes or Interfaces" (on
page 179) for more information.
You can create any number of Node Groups in addition to the ones that NNMi provides (see "Node Groups
Provided by NNMi" (on page 207)).
Node Group definitions match the way your team identifies important network devices. Each node group is
defined using one or more of the following:
l
Device Filters (by any combination of SNMP device category, vendor, family, profile)
l
Additional Filters (Boolean expressions based on a list of object attributes)
Page 179 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
l
Additional Nodes (identified by case-sensitive Hostname)
l
Child Node Groups (use any combination of Node Groups to create a filter)
NNMi combines the results of all Node Group configuration settings in the following manner:
l
NNMi first evaluates Device Filters. If any exist, nodes must match at least one specification to belong
to this Node Group.
l
NNMi then evaluates any Additional Filters. Nodes must also pass all Additional Filters specifications
to belong to this Node Group.
l
Any Additional Nodes specified are always included in the Node Group, irregardless of any filters.
l
Any Child Node Group results are treated the same as Additional Nodes.
To create Node Groups, do one or more of the following:
l
"In the Console, Create Node Groups" (on page 180)
l
"In a CSV File, Define Node Groups" (on page 194)
To verify the contents of a Node Group:
After the Node Group is saved, from the Node Group form, select Actions → Show Members. Special
Actions are available for Node Groups and Interface Groups.
In the Console, Create Node Groups
Node Groups are used for a variety of purposes in NNMi. See "Creating Groups of Nodes or Interfaces" (on
page 179) for more information.
You can create any number of Node Groups in addition to the ones that NNMi provides (see "Node Groups
Provided by NNMi" (on page 207)).
To create a Node Group (if your role allows you to do this):
1. Navigate to the Node Group form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Node Groups view.
c. Do one of the following:
o To create a Node Group, click the
o To edit a Node Group, click the
New icon.
Open icon in the row representing the Node Group you
want to edit.
2. In the Node Group form, provide the required information in the Basics section.
3. (NNM iSPI Performance) Make the Node Group available within NNM iSPI Performance products
(see NNM NNM iSPI Performance table).
4. Identify the nodes that belong to this Node Group.
Do one or more of the following:
n
Specify a filter based on Device Profile settings using the Device Filters tab (any combination of
category, vendor, family, or profile).
Page 180 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Tip: To base your filter on the SNMP system Object ID number, use the Additional Filters
sysOidNode code.
n
Specify a Node Group filter using the Additional Filters tab (use a variety of available codes to
filter by object attribute values in the NNMi database).
n
Specify individual nodes using the Additional Nodes tab (provide a list of Hostnames, as they
appear in the NNMi database).
n
Specify Child Node Groups using the Child Node Groups tab (use combinations of Node Groups
to create a filter).
5. Click
6. Click
Save and Close to return to the Node Group form.
Save and Close.
If you configured this Node Group for Monitoring, NNMi applies your changes during the next
monitoring cycle. "Configure Monitoring Behavior" (on page 214).
To review a Node Group definition:
1. From the workspace navigation panel, select the Inventory workspace.
2. Select the Node Groups view.
3. Locate the row representing the Node Group settings you want to see and click the
Open icon.
4. The Node Group form displays.
Note: NNMi monitors the status of each Node Group over time. To check Node Group status
information, access the Node Group form's Status tab.
5. When finished, click the
Close icon.
Special Actions are available for Node Groups and Interface Groups.
Related Topics
"In a CSV File, Define Node Groups" (on page 194)
Specify Node Group Additional Filters
Use the Additional Filters Editor to create expressions that refine the requirements for membership in a
Node Group. Make sure to design any complex Additional Filters offline as a Boolean expression first. This
method can help to minimize errors when entering your expressions using the Additional Filters Editor.
If any Additional Filters are created, NNMi combines any Device Filters and Additional Filters using the
AND Boolean operator as follows:
l
NNMi first evaluates any Device Filters. Nodes must match at least one Device Filter specification to
belong to this Node Group.
l
NNMi then evaluates the Additional Filters expression. Nodes must also match all Additional Filters
expression specifications to belong to this Node Group.
To create an Additional Filters expression:
1. Navigate to the Node Group Form: Additional Filters tab.
a. From the workspace navigation panel, select the Configuration workspace.
Page 181 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
b. Select Node Group.
c. Do one of the following:
o To create a Node Group definition, click the
o To edit a Node Group definition, click the
New icon.
Open icon in the row representing the Node
Group definition you want to edit.
d. In the Node Group form, select the Additional Filters tab.
2. Establish the appropriate settings for the Additional Filters you need (see the Additional Filters Editor
Components and Additional Filters Editor Buttons table). See "Guidelines for Creating Additional
Filters for Node Groups" (on page 189) for more information.
a. Plan out the logic needed for your Filter String.
b. Use the buttons on the bottom half of the Additional Filters Editor to establish the logic
structure. See "Add Boolean Operators in the Additional Filters Editor" (on page 191).
For example, to establish the following structure, select Insert, then click AND, then NOT, and
then AND a second time:
(( ) AND NOT ( ))
c. Now place your cursor in a location within the displayed Filter String, and use the top half of
the filter editor to define the parameters of the selected filter requirement.
For example, select a set of parentheses and use the Insert button to specify the filter
requirement within those parentheses:
3. Click
Save and Close.
Additional Filters Editor Components for Node Groups
Attribute
Description
Attribute
NNMi provides Additional Filters codes for a subset of object attributes. For more information
about the available Additional Filter codes for each NNMi object type, click the link:
l
Node attribute codes [click here for a list of attribute codes]
Page 182 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
Values from the Basic Attributes listed on the Node Form:
n
hostname (Hostname, case-sensitive)
n
mgmtIPAddress (Management Address)
n
isSnmpNode (Agent Enabled)
n
isNnmSystemLocal (NNMi Management Server)
Values from the Node Form:General Tab:
n
sysName (System Name)
n
sysLocation (System Location)
n
sysContact (System Contact)
n
sysOidNode (System Object ID)
Addresses from the Node Form: IP Addresses Tab:
n
hostedIPAddress (Address)
See "Node Groups of IPv4 or IPv6 Addresses " (on page 188) for ideas.
Unique Keys from the Node Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Node Form: Custom Attributes Tab:
Note: When using customAttrNameand customAttrValue pairs, use EXISTS if you
want NNMi to consider Nodes that do not have Custom Attributes when evaluating
the entire Filter String. Otherwise Nodes that do not have Custom Attributes are
automatically excluded from the Node Group even if they have values that pass
other aspects of your filter.
l
n
customAttrName (Custom Attribute Name)
n
customAttrValue (Custom Attribute Value)
Device Profile attribute codes [click here for a list of attribute codes]
Values from the Basics Attributes on the Device Profile Form:
NNMi matches the Label attribute values from the Device Profile Form for each of the
following:
n
devCategoryNode (Device Category)
n
devVendorNode (Device Vendor)
n
devFamillyNode (Device Family)
To filter on the SNMP system object ID number assigned to a particular make/model, use
the sysOidNode attribute. See Values from the Node Form: General Tab.
l
Regional Manager attribute codes [click here for a list of attribute codes]
Values from the associated entry on the Regional Manager Form: Connection Tab:
n
nnmSystemName (Hostname, case-sensitive)
(NNMi Advanced) If the Global Network Management feature is enabled, this attribute
Page 183 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
value identifies a Regional Manager (NNMi management server).
Operator
The standard query language (SQL) operations to be used for the search.
Note: Only the is null Operator returns null values in its search.
Valid operators are described below.
l
= Finds all values equal to the value specified. Click here for an example.
Example: sysName = cisco2811 finds all devices with system name equal to
cisco2811.
l
!= Finds all values not equal to the value specified. Click here for an example.
Example: sysName != cisco2811 finds all system names other than cisco2811.
l
< Finds all values less than the value specified. Click here for an example.
IPv4 example: mgmtIPAddress < 15.239.255.255 finds all IP address values less
than 15.239.255.255
IPv6 example: mgmtIPAddress < ::ffff:0:0 finds all IP address values less than
::ffff:0:0
l
<= Finds all values less than or equal to the value specified. Click here for an example.
Example: mgmtIPAddress <= 15.239.255.255 finds all IP address values less than
or equal to 15.239.255.255.
l
> Finds all values greater than the value specified. Click here for an example.
IPv4 example: mgmtIPAddress > 15.238.0.0 finds all IP address values greater than
15.238.0.0
IPv6 example: mgmtIPAddress > ::ffff:ffff:ffff finds all IP address values
greater than ::ffff:ffff:ffff
l
>= Finds all values greater than or equal to the value specified. Click here for an
example.
Example: mgmtIPAddress >= 15.238.0.0 finds all IP address values greater than or
equal to 15.238.0.0.
l
between Finds all values equal to and between the two values specified. Click here for
an example.
Example: mgmtIPAddress between 15.238.0.10 15.238.0.120 finds all IPv4
address values equal to or greater than 15.238.0.10 and equal to or less than
15.238.0.120.
See "Node Groups of IPv4 or IPv6 Addresses " (on page 188) for more examples of using
the between Operator.
l
in Finds any match to at least one value in a list of values. Click here for an example.
Example:
sysName in
Page 184 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
finds all systems with names that are cisco2811 or cisco5500.
Note: As shown in the example, each value must be entered on a separate line.
NNMi displays the list of attributes using comma-separated values enclosed in
parentheses, for example (cisco2811, cisco550). However, the comma-separated list is
used only for display purposes. The actual delimiter is the new line.
l
is not null Finds all non-blank values. Click here for an example.
Example: sysName is not null finds all systems that have a name value.
l
is null Finds all blank values. Click here for an example.
Example: sysName is null finds all systems that do not have an assigned name value.
l
like Finds matches using wildcard characters. Click here for more information about
using wildcard characters.
The following attributes cannot be used with the like operator:
n
hostedIPaddress
n
mgmtIPaddress
The asterisk (*) character means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Examples:
l
n
sysName like cisco* finds all system names that begin with cisco.
n
sysName like cisco??* finds all system names that start with cisco followed by
two characters.
n
sysName like rtr??bld5* finds all system names that have specific characters at
an exact location, positions 1-3 (rtr) and 6-9 (bld5).
not between finds all values except those between the two values specified. Click here
for an example.
Example: mgmtIPAddress not between 15.238.0.10 15.238.0.120 finds all IP
address values less than 15.238.0.10 and greater than 15.238.0.120.
See "Node Groups of IPv4 or IPv6 Addresses " (on page 188) for more examples of using
the not between Operator.
l
not in Finds all values except those included in the list of values. Click here for an
example.
Example:
sysName not in
finds all system name values other than cisco2811 and cisco5500.
Note: As shown in the example, each value must be entered on a separate line.
NNMi displays the list of attributes using comma-separated values enclosed in
Page 185 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
parentheses, for example, (cisco2811, cisco550). However, the comma-separated list is
used only for display purposes. The actual delimiter is the new line.
l
not like Finds all that do not have the values specified (using wildcard strings). Click here
for an example.
The following attributes cannot be used with the not like operator:
n
hostedIPaddress
n
mgmtIPaddress
The asterisk (*) character means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Examples:
n
sysName not like cisco* finds all system names that do not begin with cisco.
n
sysName not like cisco??* finds all system names that do not begin with cisco
followed by two characters.
n
sysName not like rtr??bld5* finds all system names that do not have specific
characters at an exact location, positions 1-3 (rtr) and 6-9 (bld5).
Page 186 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
Value
The value for which you want NNMi to search.
Note the following:
l
The values you enter are case sensitive.
l
NNMi displays a variable number of value fields depending on the Operator selected.
For example, the between Operator causes two value fields to be displayed.
l
The in and not in operators require that each value be entered on a separate line.
l
When entering a value for the Capability attribute, copy and paste the Unique Key value
from the Node form: Capability tab.
Additional Filters Editor Buttons
Button
Description
Append
Appends the current expression (Attribute, Operator,and Value) to the selected expression
already included in the Filter String.
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor location
within the Filter String.
Replace
Replaces the selected expression with the expression displayed in the Attribute, Operator,
and Value fields.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the expression as
it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the expression as
it is created.
NOT
Can be used in any part of the Filter String to specify that NNMi should exclude nodes with
values that pass the expression that immediately follows the NOT.
For example, when evaluating the following Filter String, NNMi includes nodes with a
hostname that contains router, followed by any number of characters, followed by hp.com
and excludes any nodes with a Device Profile that includes Cisco as the Vendor value:
(hostname like router*.hp.com OR NOT (devVendorNode = Cisco))
EXISTS
Used for filters that include Capabilities or Custom Attribute names and values in the Filer
String. Indicates that you want NNMi to consider nodes that do not have any Capabilities or
Custom Attributes when evaluating the Filter String.
Note: If you include Capabilities or Custom Attribute names and values in the Filer String, but
do not use EXISTS or NOT EXISTS, NNMi excludes from its search nodes that do not
include Capabilities or Custom Attributes.
For example, when evaluating the following Filter String, NNMi includes nodes with a
hostname that includes router, followed by any number of characters, followed by hp.com as
well as any nodes that have the Custom Attribute edge and that edge value is true:
(hostname like router*.hp.com OR EXISTS((customAttrName=edge AND
Page 187 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Button
Description
customAttrValue=true)))
NOT
EXISTS
Used for filters that include Capabilities or Custom Attribute names and values in the Filer
String. Indicates that you want NNMi to consider nodes that do not have any Capabilities or
Custom Attributes when evaluating the Filter String, but exclude the nodes that match the
expression that follows the NOT EXISTS.
Note: If you include Capabilities or Custom Attribute names and values in the Filer String, but
do not use EXISTS or NOT EXISTS, NNMi excludes from its search nodes that do not
include Capabilities or Custom Attributes.
For example, when evaluating the following Filter String, NNMi includes nodes with a
hostname that includes router, followed by any number of characters, followed by hp.com
and excludes any nodes with Custom Attribute edge and that edge value is true.
(hostname like router*.hp.com OR NOT EXISTS((customAttrName=edge AND
customAttrValue=true)))
Delete
Deletes the selected expression.
Note: If the Boolean Operator is selected, the Additional Filters Editor deletes all expressions
associated with the Boolean Operator.
Node Groups of IPv4 or IPv6 Addresses
Use the Node Group form's Additional Filters editor to create Node Groups based on the following criteria
("Specify Node Group Additional Filters" (on page 181)):
l
All nodes that have only IPv4 addresses
[click here for details of this filter.]
Both of the following example Node Group's Additional Filters provide the same results. The first
example uses IPv4 address notation. The second example uses IPv6 address notation:
((hostedIPAddress between 0.0.0.0 AND 255.255.255.255) AND NOT (hostedIPAddress
not between 0.0.0.0 AND 255.255.255.255))
or (NNMi Advanced with IPv6 enabled)
((hostedIPAddress between 0.0.0.0 AND 255.255.255.255) AND NOT (hostedIPAddress
not between ::ffff:0:0 AND ::ffff:ffff:ffff))
l
All nodes that have any IPv4 addresses (could also have IPv6)
[click here for details of this filter.]
The following example Node Group's Additional Filter finds any node that has at least one IPv4
address:
(hostedIPAddress between 0.0.0.0 AND 255.255.255.255)
l
(NNMi Advanced with IPv6 enabled) All nodes that have only IPv6 addresses
[click here for details of this filter.]
IPv6 addresses extend the number of possible IP addresses. The old IPv4 address range falls within
the new IPv6 range. Valid IPv6 address values can be less than or greater than the old IPv4 range of
Page 188 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
addresses. NNMi Advanced converts the IPv4 addresses to the new IPv6 notation, then stores and
filters the IPv4 addresses as IPv6 addresses (::ffff:a.b.c.d).
Both of the following example Node Group's Additional Filters provide the same results. The first
example uses IPv4 address notation. The second example uses IPv6 address notation:
((hostedIPAddress not between 0.0.0.0 AND 255.255.255.255) AND NOT
(hostedIPAddress between 0.0.0.0 AND 255.255.255.255))
or
((hostedIPAddress not between ::ffff:0:0 AND ::ffff:ffff:ffff) AND NOT
(hostedIPAddress between 0.0.0.0 AND 255.255.255.255))
l
(NNMi Advanced with IPv6 enabled) All nodes that have any IPv6 addresses (could also have IPv4)
[click here for details of this filter.]
The following example Node Group's Additional Filter finds any node that has at least one IPv6
address:
((hostedIPAddress between ::0 AND ::fffe:ffff:ffff) OR (hostedIPAddress
::1:0:0:0 AND ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff))
l
(NNMi Advanced with IPv6 enabled) All nodes that have both IPv4 and IPv6 addresses (also known as
dual-stack nodes)
[click here for details of this filter.]
The following example Node Group's Additional Filter finds any node that has at least one IPv4
address and at least one IPv6 address:
((hostedIPAddress between 0.0.0.0 AND 255.255.255.255) AND (hostedIPAddress not
between 0.0.0.0 AND 255.255.255.255))
Note: To maximize the performance of Additional Filters based on an IP Address range, avoid multiple
filter expressions. For example, use the between operator instead of the greater than or equal to
(>=) and less than or equal to (<=) operators that cause NNMi to use multiple queries for finding all
addresses that match the filter.
Guidelines for Creating Additional Filters for Node Groups
The Additional Filters Editor enables you to create expressions to further define the nodes to be included
in a Node Group. Make sure to design any complex Additional Filters offline as a Boolean expression first.
This method can help to minimize errors when entering your expressions using the Additional Filters
Editor.
When creating Additional Filters for a Node Group, note the following:
l
NNMi treats each set of expressions associated with a Boolean Operator as if it were enclosed in
parentheses and evaluated together rather than in order of grouping as the nesting implies. Therefore,
when using the AND operator to combine expressions that include Custom Attributes, include only one
customAttrName/customAttrValue pair in the expression. Otherwise, if you use multiple
customAttrName and customAttrValue pairs with the AND operator, the results might not be as
expected. Click here for an example.
In the following example, because the AND Boolean operator indicates that NNMi should evaluate all of
Page 189 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
the customAttrname and customAttrvalue pairs together, it is not possible for any nodes to match
this Additional Filters expression:
Additional Filter Expression Example 1:
((customAttrName = capability) AND (customAttrValue =
com.hp.nnm.capability.card.fru)) AND ((customAttrName = location) AND
(customAttrValue = datacenter1))
This is because customAttrName would need to match both capabilityand >location at the same
time. However, if you use the OR operator to combine the customAttrName and customAttrValue
pairs as shown in the following example, the filter should work as expected.
Additional Filter Expression Example 2:
((customAttrName = capability) AND (customAttrValue =
com.hp.nnm.capability.card.fru)) OR ((customAttrName = location) AND
(customAttrValue = datacenter1))
Using the Node values listed in the following table, all three nodes (nodeA, nodeB, and nodeC) pass
the filter in Example 2 because each of these nodes has either the value
com.hp.nnm.capability.card.fru for capabilityor the value datacenter1 for location.
Example Data
Node Name
capabilty
customAttrName
customAttrValuee
nodeA
com.hp.nnm.capability.card.fru
location
datacenter1
nodeB
com.hp.nnm.capability.card.fru
<undefined>
<undefined>
nodeC
<undefined>
location
datacenter1
l
Use the EXISTS and NOT EXISTS operators when you want NNMi to consider nodes that do not have
any Capabilities or Custom Attributes when evaluating the Filter String. See "Specify Node Group
Additional Filters" (on page 181) for more information.
l
View the expression displayed under Filter String to see the logic of the expression as it is created.
l
The AND and OR Boolean Operators must contain at least two expressions as shown in the example
below.
AND
sysName like cisco*
sysName != cisco2811
OR
sysLocation = Boston
sysContact In (Johnson,Hickman)
NNMi evaluates the expression above as follows:
sysName like cisco* AND sysName != cisco2811 AND (sysLocation = Boston OR
sysContact in (Johnson, Hickman))
n
NNMi finds all nodes with a (system name) sysName beginning with cisco, except not cisco2811.
n
Of these nodes, NNMi then finds all nodes with a (system location) sysLocation of Boston or
(system contact name) sysContact of Johnson or Hickman.
Page 190 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
l
NNMi evaluates only those nodes that contain values for all of the attributes included in the Additional
Filter expression. Click here for an example.
If your Node Group filter expression includes the capability and customAttrName attributes, then
NNMi evaluates only nodes that have a value defined for bothcapability and customAttrName. For
example, if you create a Node Group using the following Additional Filters expression, then NNMi
evaluates only those nodes that have a value defined for capability and a value defined for
customAttrName:
(capability = com.hp.nnm.capability.card.fru) OR (customAttrName = location)
Using the Node values listed in the following table, NNMi only evaluates nodeA. This is because
nodeA contains a value for capability and a value for customAttrName. NNMi does not evaluate
nodeB because it does not have a value for customAttrName. NNMi does not evaluate nodeC
because it does not have a value for capability. NodeA also passes Node Group Additional Filter
because its capability value of com.hp.nnm.capability.card.fru matches the value specified
in the Additional Filter expression. Therefore, only nodeA is included in this example Node Group.
Example Data
Node Name
capabilty
customAttrName
customAttrValuee
nodeA
com.hp.nnm.capability.card.fru
location
datacenter1
nodeB
com.hp.nnm.capability.card.fru
<undefined>
<undefined>
nodeC
<undefined>
location
datacenter1
Tip: You can populate a placeholder value, such as "none" or "undefined" for any attribute that you
want to use in an Additional Filter.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
l
You can drag any of the following items to a new location in the Filter String:
l
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
n
Click the item you want to move before dragging it to a new location.
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
n
If you are moving the selection down, NNMi places the item below the target location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an error message.
Add Boolean Operators in the Additional Filters Editor
When adding or deleting Boolean Operators using the Additional Filters Editor, note the following:
Page 191 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
l
Add your highest level Boolean operator first. For example, AND is the highest level Boolean operator
in the following expression
(sysName like cisco* OR sysName like hp*) AND ( sysLocation = Boston OR sysContact in
Johnson,Hickman)
l
Add each additional Boolean Operator before the expressions to which it applies.
l
Select the appropriate Boolean Operator in the expression before you add the expressions to which
the Boolean Operator applies.
l
When a Boolean Operator is selected and you click Delete, any expressions that are associated with
the Boolean Operator are also deleted.
In the example expression below, If you select AND and then click Delete, the Additional Filters Editor
deletes the entire expression.
Click here for an example for creating Node Group Additional Filters.
Node Group Additional Filters Expression Example
((sysName like cisco* OR sysName like hp*) AND (sysLocation = Boston OR sysContact
in (Johnson, Hickman)))
To add the expression above, after you are in the Additional Filters Editor, follow these steps:
1. Click AND.
2. Click OR.
3. Select the OR you just added to the expression.
4. In the Attribute field select sysName from the drop-down list.
5. In the Operator field, select like from the drop-down list.
6. In the Value field, enter cisco*.
7. Click Append.
8. In the Attribute field, select sysName from the drop-down list.
9. In the Operator field, select like from the drop-down list.
10. In the Value field, enter hp*.
11. Click Append.
12. Select the AND that you previously added to the expression.
13. Click OR.
14. Select the OR you just added to the expression.
15. In the Attribute field, select sysLocation from the drop-down list.
16. In the Operator field, select = from the drop-down list.
17. In the Value field, enter Boston.
Page 192 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
18. Click Append.
19. In the Attribute field, select sysContact from the drop-down list.
20. In the Operator field, select in from the drop-down list.
21. In the Value field:
a. enter Johnson and press <Enter>.
b. On the new line, enter Hickman.
22. Click Append.
23. Click Save to save your Additional Filters.
24. Select Actions → Show Members to view the members of the Node Group that is a result of this
filter.
Click here for an example for creating an Interface Group Additional Filters.
Interface Group Additional Filters Expression Example
((ifName like ATM* AND ifName != ATMS/O/A) AND (ifSpeed = 10 OR ifSpeed = 100))
To add the expression above, follow these steps:
1. Click AND.
2. Click AND.
3. Select the AND you just added to the expression.
4. In the Attribute field select ifName from the drop-down list.
5. In the Operator field, select like from the drop-down list.
6. In the Value field, enter ATM*.
7. Click Append.
8. In the Attribute field, select ifName from the drop-down list.
9. In the Operator field, select !=not equal to from the drop-down list.
10. In the Value field, enter ATMS/0/A.
11. Click Append.
12. Select the first AND that you added to the expression.
13. Click OR.
14. Select the OR you just added to the expression.
15. In the Attribute field, select ifSpeed from the drop-down list.
16. In the Operator field, select = from the drop-down list.
17. In the Value field, enter 10.
18. Click Append.
19. In the Attribute field, select ifSpeed from the drop-down list.
20. In the Operator field, select = from the drop-down list.
Page 193 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
21. In the Value field, enter 100.
22. Click Append.
23. Click Save to save your Additional Filters.
24. Select Actions → Show Members to view the members of the Node Group that is a result of this
filter.
In a CSV File, Define Node Groups
Node Groups are used for a variety of purposes in NNMi. See "Creating Groups of Nodes or Interfaces" (on
page 179) for more information.
You can create any number of Node Groups in addition to the ones that NNMi provides (see "Node Groups
Provided by NNMi" (on page 207)).
You can create a Node Group by either using the NNMi console or a comma separated values (CSV) file.
For example, if you have Node Group information in a Microsoft Excel spreadsheet, you can save this
information as a .csv file and use the nnmloadnodegroups.ovpl command to add this node group
information to NNMi.
Certain columns in the CSV file define the following aspects of the Node Group:
l
Columns 1-3 define the Basic settings.
l
Optional. Column 4 defines Child Node Groups settings.
Any Child Node Group members are always included in the Node Group, irregardless of any filters.
The specified Child Node Groups must already exist in NNMi or be defined in the CSV file in addition
to the Parent Node Group.
l
Optional. Column 5 defines Device Filters settings.
NNMi first evaluates Device Filters. If any are defined, Nodes must match at least one specification to
belong to this Node Group.
l
Optional. Column 6 defines Additional Nodes settings.
Any Additional Nodes specified are always included in the Node Group, irregardless of any filters.
l
Optional. Columns 7-11 define Additional Filters (only a subset of codes are available in the CSV file,
see nnmloadnodegroups.ovpl for the current list. You must use the NNMi console to define the Node
Group if you need other choices).
Note: If you do not like the Boolean logic assigned by default when you import your CSV file, use the
Additional Filters Editor to change things after importing.
If a Node passes the Device Filters, NNMi then evaluates any Additional Filters. Nodes must also pass
all Additional Filters specifications to belong to this Node Group.
To create a Node Group using a comma separated values (CSV) text file, use the
nnmloadnodegroups.ovpl command:
See the nnmloadnodegroups.ovpl Reference Page for more information about the
nnmloadnodegroups.ovpl command, including requirements for the CSV file. You must provide a CSV
file with a specific syntax and order. Each column in the CSV file has a pre-defined meaning.
Tip: If your goal is to merge new information into an existing Node Group, use nnmloadnodegroups.ovpl to
create a new Node Group with the additional settings. Then use the Node Group form to assign that
new Node Group as a Child Node Group of the original Node Group.
Page 194 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
nnmloadnodegroups.ovpl -r [true|false] -u <NNMiadminUsername> -p
<NNMiadminPassword> -f <CSV file name>
CSV file name is the name of the CSV file that contains the Node Group information.
-r true means all the settings for any existing Node Group with the same Name are overwritten with the
values in your CSV file. This is not a merge, it is a complete replacement of that Node Group configuration!
-r false (defautl) means if the Node Group Name already exists, the nnmloadnodegroups.ovpl
command does not change the previous settings.
Create Interface Groups
Node Groups are used for a variety of purposes in NNMi. See "Creating Groups of Nodes or Interfaces" (on
page 179) for more information.
Interface Group definitions match the way your team identifies important network devices. Each interface
group can include one or more interface-type specifications (based on industry-standard IANA ifType-MIB
variables).
You can create any number of Interface Groups in addition to the ones that NNMi provides (see "Interface
Groups Provided by NNMi" (on page 210)).
When determining membership in this Interface Group, NNMi combines the results of all Interface Group
configuration settings in the following manner:
l
NNMi first evaluates ifType Filters. If any exist, interfaces must match at least one specification to
belong to this Interface Group.
l
NNMi then evaluates any Additional Filters. Interfaces must also pass all Additional Filters
specifications to belong to this Interface Group.
l
If a Node Group is specified for this Interface Group, any interface in this group must be contained in a
node that is a member of the Node Group specified in the Basics section.
Interface Groups are used for a variety of purposes in NNMi:
l
Interface Groups are filters for interface views, IP address views, HP Network Node Manager iSPI
Performance for Metrics Software, and HP Network Node Manager iSPI Performance for Traffic
Software.
l
Interface Groups can control how NNMi monitors network devices. For example, instruct NNMi to never
generate ICMP or SNMP queries to any interface used for Voice-Over-IP within your network.
To define an Interface Group (if your role allows you to do this):
1. Navigate to the Interface Group form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Interface Groups view.
c. Do one of the following:
o To create an Interface Group, click the
o To edit an Interface Group, click the
New icon.
Open icon in the row representing the Interface
Group you want to edit.
Page 195 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
2. Provide the Basics for this interface group, such as Name, Notes, and behavior designations (see
Interface Group Form help).
3. Optional. Navigate to the Interface Type Filters tab.
Identify one or more interface types that belong to this group:
n
To add an Interface Type filter, click the
n
To change an Interface Type filter, click the
configuration you want to edit, and continue.
n
To delete an Interface Type filter, select a row and click the
4. In the Interface Type Filter form, click the
drop-down menu:
Delete icon.
Lookup icon and select one of the options from the
Quick Find to view and select from the list of all existing IfTypes (for more information see "Use
the Quick Find Window" (on page 28)).
n
n
Open icon in the row representing the
Quick View to display summary information for the currently selected IfType.
n
n
New icon, and continue.
Open to display the details of the currently selected IfType.
New to create a new IfType (see "Add New IfTypes (Interface Types) to the List" (on page
206)).
5. Optional. Navigate to the Additional Type Filters tab.
Use the Additional Filters Editor to filter based on the current values of a subset of Interface object
attributes. See "Specify Interface Group Additional Filters" (on page 196).
6. Click
Save and Close to return to the Interface Group form.
7. Click
Save and Close.
If you configured this Interface Group for Monitoring, NNMi applies your changes during the next
monitoring cycle. See "Configure Monitoring Behavior" (on page 214).
To review an Interface Group definition:
1. From the workspace navigation panel, select the Inventory workspace.
2. Select the Interface Groups view.
3. Locate the row representing the Interface Group and click the
Open icon.
4. The Interface Group form displays.
5. When finished, click the
Close icon.
Special Actions are available for Node Groups and Interface Groups.
Specify Interface Group Additional Filters
The Additional Filters Editor enables you to create expressions to further define the interfaces to be
included in an Interface Group. Make sure to design any complex Additional Filters offline as a Boolean
expression first. This method can help to minimize errors when entering your expressions using the
Additional Filters editor.
If any Additional Filters are created:
Page 196 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
l
NNMi first evaluates any Interface Type filter. Nodes must match at least one specification to belong to
this Interface Group.
l
NNMi then evaluates the Additional Filters expression. Nodes must also match all Additional Filters
expression specifications to belong to this Interface Group.
To create any Additional Filters expression:
1. Navigate to the Interface Group Form: Additional Filters tab.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Interface Groups.
c. Do one of the following:
o To create an Interface Group definition, click the
o To edit an Interface Group definition, click the
New icon.
Open icon in the row representing the
configuration you want to edit.
d. In the Interface Group form, select the Additional Filters tab.
2. Establish the appropriate settings for the Additional Filters you need. (See the Additional Filters
Editor Components, Additional Filters Editor Buttons table. See also "Guidelines for Creating
Additional Filters for Interface Groups" (on page 205).)
a. Plan out the logic needed for your Filter String.
b. Use the buttons on the bottom half of the Additional Filters Editor to establish the logic
structure.
For example, to establish the following structure, select Insert, then click AND, then NOT, and
then AND a second time:
(( ) AND NOT ( ))
c. Now place your cursor in a location within the displayed Filter String, and use the top half of
the filter editor to define the parameters of the selected filter requirement.
Page 197 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
For example, select a set of parentheses and use the Insert button to specify the filter
requirement within those parentheses:
3. Click
Save and Close.
Additional Filters Editor Components for Interface Groups
Attribute
Description
Attribute
NNMi provides Additional Filters codes for a subset of object attributes. For more information
about each one, click the link:
l
Interface attribute codes [click here for a list of attribute codes]
Values from the Basic Attributes listed on the Interface Form:
n
ifName (Name)
n
hostedOn (Hosted On Node)
n
ifPhysAddress (Physical Address)
Values from the Interface Form: General Tab:
n
ifAlias (InterfaceAlias)
n
ifDesc (InterfaceDescription)
n
ifIndex (InterfaceIndex)
n
ifSpeed (Interface Speed)
Addresses from the Interface Form: IP Addresses Tab:
n
ipAddress (IP Address associated with the interface)
See "Interface Groups of IPv4 or IPv6 Addresses " (on page 204) for ideas.
Unique Keys from the Interface Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Interface Form: Custom Attributes Tab:
Page 198 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
Note: When using customAttrNameand customAttrValue pairs, use EXISTS if you
want NNMi to consider Nodes that do not have Custom Attributes when evaluating
the entire Filter String. Otherwise Nodes that do not have Custom Attributes are
automatically excluded from the Node Group even if they have values that pass
other aspects of your filter.
l
n
customAttrName (Custom Attribute Name)
n
customAttrValue (Custom Attribute Value)
Node attribute codes [click here for a list of attribute codes]
Values from the Basics information on the Node Form:
n
isSnmpInterface (Agent Enabled)
Values from the Node Form: General Tab.
n
l
sysOidInterface (System Object ID)
Device Profile attribute codes [click here for a list of attribute codes]
Values from the Basics information on the Device Profile Form:
NNMi matches the Label attribute values from the Device Profile Form for each of the
following:
n
devCategoryInterface (Device Category)
n
devVendorInterface (Device Vendor)
n
devFamilyInterface (Device Family)
To filter on the parent node's SNMP system object ID number (assigned to a particular
make/model), use the sysOidInterface attribute. See Values from the Interface Form:
General Tab.
l
VLAN attribute codes [click here for a list of attribute codes]
Values from the Basic Attributes on the VLAN form::
Note: To maximize performance, when you want to filter interfaces based on a VLAN Id
or VLAN Name, avoid using multiple filter expressions. For example, use the
between operator instead of the greater than or equal to (>=) and less than or
equal to (<=) operators.
l
n
vlanid (VLAN Id)
n
vlanName (Name)
Port attribute codes [click here for a list of attribute codes]
Values from the Basic Attributes on the Port form::
Note: If the interface has multiple ports, the interface is selected if there is a match on any
one port associated with the interface.
n
configuredDuplexSetting (Configured Duplex Setting)
See Port form for a list of possible values.
Operator
The standard query language (SQL) operations to be used for the search.
Page 199 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
Note: Only the is null Operator returns null values in its search.
Valid operators are described below.
l
= Finds all values equal to the value specified. Click here for an example.
Example: ifName=Fa0/14 finds all interface names that are equal to Fa0/14.
l
!= Finds all values not equal to the value specified. Click here for an example.
Example:ifName != lan0 finds all interface names other than lan0.
l
< Finds all values less than the value specified. Click here for an example.
Example: ifSpeed <= 100000000 finds all interfaces with an (interface speed)
ifSpeed less than 100 Mbps.
l
<= Finds all values less than or equal to the value specified. Click here for an example.
Example: ifSpeed <= 100000000 finds all interfaces with an (interface speed)
ifSpeed less than or equal to 100 Mbps.
l
> Finds all values greater than the value specified. Click here for an example.
Example: ifSpeed >= 10000000 finds all interfaces with an (interface speed) ifSpeed
greater than 10 Mbps.
l
>= Finds all values greater than or equal to the value specified. Click here for an
example.
Example: ifSpeed >= 10000000 finds all interfaces with an (interface speed) ifSpeed
greater than or equal to 10 Mbps.
l
between Finds all values equal to and between the two values specified. Click here for
an example.
Example: ifSpeed between 10000000 100000000 finds all interfaces with an
(interface speed) ifSpeed equal to or greater than 10 Mbps and equal to or less than 100
Mbps.
See "Interface Groups of IPv4 or IPv6 Addresses " (on page 204) for more examples of
using the between Operator.
l
in Finds any match to at least one value in a list of values. Click here for an example.
Example:
ifName in
finds all interfaces with names that are Fa0/14 or Fa0/15.
Note: As shown in the example, each value must be entered on a separate line.
NNMi displays the list of attributes using comma-separated values enclosed in
parentheses, for example, (Fa0/14, Fa0/15). However, the comma-separated list is used
only for display purposes. The actual delimiter is the new line.
l
is not null Finds all non-blank values. Click here for an example.
Example: ifName is not null finds all interfaces that have a name value.
Page 200 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
l
is null Finds all blank values. Click here for an example.
Example:ifName is null finds all interfaces that do not have an assigned name value.
l
like Finds matches using wildcard characters. Click here for more information about
using wildcard characters.
The following attributes cannot be used with the like operator:
n
ifIndex
n
ifSpeed
n
IPAddress
The asterisk (*) character means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Examples:
l
n
ifName like ATM* finds all interface names that begin with ATM.
n
ifName like Ethernet??* finds all interface names that begin withEthernet
followed by two characters.
n
ifName like 10/???BASE-TX* finds all interface names that have specific
characters at an exact location, positions 1-3 (10/) and 7-13 (BASE-TX).
not between Finds all values except those between the two values specified. Click here
for an example.
Example: ifSpeed not between 10000000 100000000 finds all interfaces with an
(interface speed) ifSpeed less than 10 Mbps and greater than 100 Mbps.
See "Interface Groups of IPv4 or IPv6 Addresses " (on page 204) for more examples of
using the not between Operator.
l
not in Finds all values except those included in the list of values. Click here for an
example.
Example:
ifName not in
finds all interface name values other than Fa0/14 or Fa0/15.
Note: As shown in the example, each value must be entered on a separate line.
NNMi displays the list of attributes using comma-separated values enclosed in
parentheses, for example, (Fa0/14, Fa0/15). However, the comma-separated list is used
only for display purposes. The actual delimiter is the new line.
l
not like Finds all that do not have the values specified (using wildcard strings). Click here
for an example.
The following attributes cannot be used with the not like operator:
n
ifIndex
Page 201 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
n
ifSpeed
n
IPAddress
The asterisk (*) character means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Examples:
n
ifName not like ATM* finds all interface names that do not begin with ATM.
n
ifName not like Ethernet??* finds all interface names that do not begin
withEthernet followed by two characters.
n
ifName not like 10/???BASE-TX* finds all interface names that do not have
specific characters at an exact location, positions 1-3 (10/) and 7-13 (BASE-TX).
Page 202 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Attribute
Description
Value
The value for which you want NNMi to search.
Note the following:
l
The values you enter are case sensitive.
l
NNMi displays a variable number of value fields depending on the Operator selected.
For example, the between Operator causes two value fields to be displayed.
l
The in and not in operators require that each value be entered on a separate line.
l
When entering a value for the Capability attribute, copy and paste the Unique Key value
from the Interface form: Capability tab.
Additional Filters Editor Buttons
Button
Description
Append
Appends the current expression (Attribute, Operator,and Value) to the selected expression
already included in the Filter String.
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor location
within the Filter String.
Replace
Replaces the selected expression with the expression displayed in the Attribute, Operator,
and Value fields.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the expression as
it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the expression as
it is created.
NOT
Can be used in any part of the Filter String to specify that NNMi should exclude interfaces with
values that pass the expression that immediately follows the NOT.
For example, when evaluating the following expression, NNMi includes interfaces with
(interface description) ifDesc containing VLAN, and excludes any Interfaces that have
VLAN10 for the (interface name) ifName value:
(ifDesc like VLAN AND NOT (ifName=VLAN10))
Note: View the expression displayed under Filter String to see the logic of the expression as
it is created.
EXISTS
Used for filters that include Capabilities or Custom Attribute names and values in the Filer
String. Indicates that you want NNMi to consider interfaces that do not have any Capabilities
or Custom Attributes when evaluating the Filter String.
Note: If you include Capabilities or Custom Attribute names and values in the Filer String, but
do not use EXISTS or NOT EXISTS, NNMi excludes from its search interfaces that do
not include Capabilities or Custom Attributes.
For example, when evaluating the following Filter String, NNMi includes interfaces with
(interface description) ifDesc containing VLAN, as well as any Interfaces Custom Attribute
Page 203 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Button
Description
Role value is LAN Connection to Oracle Server:
(ifDesc like VLAN OR EXISTS((customAttrName=Role AND customAttrValue=LAN
Connection to Oracle Server)))
Note: View the expression displayed under Filter String to see the logic of the expression as
it is created.
NOT
EXISTS
Used for filters that include Capabilities or Custom Attribute names and values in the Filer
String. Indicates that you want NNMi to consider interfaces that do not have any Capabilities
or Custom Attributes when evaluating the Filter String, but exclude the interfaces that match
the expression that follows the NOT EXISTS.
Note: If you include Capabilities or Custom Attribute names and values in the Filer String, but
do not use EXISTS or NOT EXISTS, NNMi excludes from its search interfaces that do
not include Capabilities or Custom Attributes.
For example, when evaluating the following expression, NNMi includes interfaces with
(interface description) ifDesc containing VLAN, and excludes any Interfaces that have the
Custom Attribute Role and that Role value is LAN Connection to Oracle Server:
(ifDesc like VLAN OR NOT EXISTS((customAttrName=Role AND
customAttrValue=LAN Connection to Oracle Server)))
Note: View the expression displayed under Filter String to see the logic of the expression as
it is created.
Delete
Deletes the selected expression.
Note: If the Boolean Operator is selected, the Additional Filters Editor deletes all expressions
associated with the Boolean Operator.
Interface Groups of IPv4 or IPv6 Addresses
Use the Interface Group form's Additional Filters Editor to create Interface Groups based on the following
criteria ("Specify Interface Group Additional Filters" (on page 196)):
l
All interfaces that have only IPv4 addresses
[click here for details of this filter.]
Both of the following example interface Group's Additional Filters provide the same results. The first
example uses IPv4 address notation. The second example uses IPv6 address notation:
((ipAddress between 0.0.0.0 AND 255.255.255.255) AND NOT (ipAddress not between
0.0.0.0 AND 255.255.255.255))
or (NNMi Advanced with IPv6 enabled)
((ipAddress between 0.0.0.0 AND 255.255.255.255) AND NOT (ipAddress not between
::ffff:0:0 AND ::ffff:ffff:ffff))
l
All interfaces that have any IPv4 addresses (could also have IPv6)
[click here for details of this filter.]
The following example interface Group's Additional Filter finds any interface that has at least one IPv4
address:
(ipAddress between 0.0.0.0 AND 255.255.255.255)
Page 204 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
l
(NNMi Advanced with IPv6 enabled) All interfaces that have only IPv6 addresses
[click here for details of this filter.]
IPv6 addresses extend the number of possible IP addresses. The old IPv4 address range falls within
the new IPv6 range. Valid IPv6 address values can be less than or greater than the old IPv4 range of
addresses. NNMi Advanced converts the IPv4 addresses to the new IPv6 notation, then stores and
filters the IPv4 addresses as IPv6 addresses (::ffff:a.b.c.d).
Both of the following example interface Group's Additional Filters provide the same results. The first
example uses IPv4 address notation. The second example uses IPv6 address notation:
((ipAddress not between 0.0.0.0 AND 255.255.255.255) AND NOT (ipAddress between
0.0.0.0 AND 255.255.255.255))
or
((ipAddress not between ::ffff:0:0 AND ::ffff:ffff:ffff) AND NOT (ipAddress
between 0.0.0.0 AND 255.255.255.255))
l
(NNMi Advanced with IPv6 enabled) All interfaces that have any IPv6 addresses (could also have
IPv4)
[click here for details of this filter.]
The following example interface Group's Additional Filter finds any interface that has at least one IPv6
address:
((ipAddress between ::0 AND ::fffe:ffff:ffff) OR (ipAddress ::1:0:0:0 AND
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff))
l
(NNMi Advanced with IPv6 enabled) All interfaces that have both IPv4 and IPv6 addresses (also
known as dual-stack interfaces)
[click here for details of this filter.]
The following example interface Group's Additional Filter finds any interface that has at least one IPv4
address and at least one IPv6 address:
((ipAddress between 0.0.0.0 AND 255.255.255.255) AND (ipAddress not between
0.0.0.0 AND 255.255.255.255))
Note: To maximize the performance of Additional Filters based on an IP Address range, avoid multiple
filter expressions. For example, use the between operator instead of the greater than or equal to
(>=) and less than or equal to (<=) operators that cause NNMi to use multiple queries for finding all
addresses that match the filter.
Guidelines for Creating Additional Filters for Interface Groups
The Additional Filters Editor enables you to create expressions to further define the interfaces to be
included in an Interface Group. Make sure to design any complex Additional Filters offline as a Boolean
expression first. This method can help to minimize errors when entering your expressions using the
Additional Filters Editor.
When creating any Additional Filters for an Interface Group, note the following:
Page 205 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
l
Each set of expressions associated with a Boolean Operator is treated as if it were enclosed in
parentheses and evaluated together. View the expression displayed under Filter String to see the
logic of the expression as it is created.
l
When using the AND operator to combine expressions that include Custom Attributes, include only one
customAttrName/customAttrValue pair in a sub-expression.
l
The AND and OR Boolean Operators must contain at least two expressions as shown in the example
below.
AND
ifName like ATMS*
ifName != ATMS/0/A
OR
ifSpeed = 10000000
ifSpeed = 100000000
Note: As shown in the example above, you must use the actual ifSpeed number.
NNMi evaluates the expression above as follows:
(ifName like ATMS* AND ifName != ATMS/0/A) AND (ifSpeed = 10000000 OR ifSpeed =
100000000)
n
NNMi finds all interfaces with an (interface name) ifName that begins with ATMS, but does not
include ATMS/0/A.
n
Of these interfaces, NNM then finds all interfaces with an (interface speed) ifSpeed of 10 Mbps or
100 Mbps.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
l
You can drag any of the following items to a new location in the Filter String:
l
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
n
Click the item you want to move before dragging it to a new location.
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
n
If you are moving the selection down, NNMi places the item below the target location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an error message.
Add New IfTypes (Interface Types) to the List
Interface Type definitions cover all known industry-standard IANA ifType-MIB variables at the time of the
release of NNMi. Interface Groups can be built using Interface Type filters. See "Create Interface Groups"
(on page 195)
The Interface Types view is provided because:
Page 206 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
l
Occasionally new Interface Types are added between releases of NNMi. If your team acquires new
devices that contain new interface types, you can add the new interface type to the NNMi list of
Interface Type definitions.
l
When NNMi discovers a new Interface Type, NNMi automatically adds a new entry in the Interface
Types view. NNMi detects the assigned IANA ifType-MIB number. NNMi uses that number in both the
IfType attribute and the number attribute values. Use this view to provide a more meaningful IfType text
string and optional description.
To configure an IANA ifType-MIB definition:
1. Navigate to the IfTypes view:
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the IfTypes view.
2. Do one of the following:
n
To create an Interface Type definition, click the
n
To edit an Interface Type definition, click the
configuration you want to edit, and continue.
n
To delete an Interface Type definition, select a row and click the
New icon, and continue.
Open icon in the row representing the
Delete icon.
3. In the Interface Type form, provide the ifType text string, number, and description.
4. Click
Save and Close.
Node Groups Provided by NNMi
NNMi Provides the following kinds of Node Groups:
l
Node Groups as Predefined View Filters. These Node Groups can also be used for Monitoring
Configuration if you find them useful.
l
"Island Node Groups" (on page 209). NNMi automatically creates Island Node Groups whenever it
detects changes in Layer 2 connections. An Island Node Group is a group of fully-connected nodes
that NNMi displays in a group that is not connected to the rest of the topology.
Node Groups As Predefined View Filters
NNMi provides the following Node Groups. You can configure these Node Groups with specific information
about your management domain and change them to meet your needs.
Node Groups can be used to filter table views, map views, HP Network Node Manager iSPI Performance
for Metrics Software, and HP Network Node Manager iSPI Performance for Traffic Software.
Node Groups Provided by NNMi
Name
Purpose
Important
Nodes
Caution: Do not delete this Node Group.
This Node Group is used by the Causal Engine. Any devices in this group receive special
treatment. When a current member of this group stops responding, the Causal Engine
generates a "Node Down" incident and sets the device status to Critical. For example,
when a WAN Edge Device is in the shadow of another problem (and, therefore, NNMi
would normally not generate an incident about that WAN edge router), NNMi generates a
Page 207 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Name
Purpose
"Node Down" incident because the router is listed in this Important Nodes group.
This Node Group is empty by default. Consider populating this group with critical servers
that run important applications and critical WAN routers.
(NNM iSPI Performance) This group automatically becomes a filter for Performance
Reports (unless the group has no members). The NNMi administrator can change this
default behavior. See "In the Console, Create Node Groups" (on page 180).
Microsoft
Windows
Systems
This Node Group includes any device manufactured by Microsoft. The Node Group
definition is populated with one vendor entry. Any Microsoft devices within your
management domain are automatically included in this Node Group.
Networking
Infrastructure
Devices
This Node Group is populated with a list of categories for network devices. Any devices
within your management domain that match these categories are automatically included
in this Node Group.
Devices in this group are automatically monitored for Node Component fault metrics.
(NNM iSPI Performance) This group automatically becomes a filter for Performance
Reports (unless the group has no members). The NNMi administrator can change this
default behavior. See "In the Console, Create Node Groups" (on page 180).
(HP Network Node Manager iSPI Network Engineering Toolset Software) By default,
NNMi automatically uses NNM iSPI NET diagnostic flows to monitor devices in this group.
Non-SNMP
Devices
This Node Group includes any device that does not respond to SNMP. The Node Group
definition is populated with one entry for a null MIB II sysObjectID value. Any device
within your management domain that fails to respond to SNMP queries is automatically
included in this Node Group.
Routers
This Node Group is populated with a list of categories for network devices that represent
routers. Any router, switch-router, or gateway within your management domain is
included in this Node Group. See Node Capabilities Provided by NNMi for more
information.
This filter is used to create the Routers Node Group map that NNMi provides by default in
the Topology Maps workspace.
Devices in this group are automatically monitored for Node Component fault metrics
(NNM iSPI Performance) Devices in this group are automatically monitored for
performance, including Node Component performance metrics . This group automatically
becomes a filter for Performance Reports.
The NNMi administrator can change this default behavior. See "Set Default Monitoring"
(on page 217), "Configure Node Monitoring" (on page 232), and "In the Console, Create
Node Groups" (on page 180) for more information.
Page 208 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Name
Purpose
Switches
This Node Group is populated with a list of categories for network devices that represent
switches. Any switch, ATM switch, or switch-router within your management domain is
included in this Node Group. See Node Capabilities Provided by NNMi for more
information.
This filter is used to create the Switches Node Group map that NNMi provides by default
in the Topology Maps workspace.
Node Groups Provided by NMi Advanced
Name
Purpose
Virtual
Machines
NNMi Advanced. Virtual machines being hosted on a VMware ESX server. These servers
are identified by a com.hp.nnm.capability.node.VM capability.
VMware
ESX
Hosts
NNMi Advanced. A VMware ESX server that is hosting virtual machines. These servers are
identified by a com.hp.nnm.capability.node.hypervisor.vmware.ESX capability.
Related Topics
"Island Node Groups" (on page 209) (dynamically generated Node Groups)
Island Node Groups
An Island Node Group is a group of fully-connected nodes discovered by NNMi, and NNMi determines this
group is not connected to the rest of the topology.
An example of an environment with multiple Island Node Groups is a financial institution or retail store with
many branches or stores. Each branch or store might be connected to other branches or stores with a
WAN (Wide Area Network) connection. Each branch or store appears as an isolated island of nodes in the
NNMi topology.
NNMi automatically updates Island Node Group discovery information whenever it detects changes in
Layer 2 connections. NNMi uses the Discovery Interval to determine when the updates actually occur.
Note the following about Island Node Groups:
l
NNMi selects a representative node in each Island Node Group as the Source Node associated with
an Island Node Group incident. The representative node is selected using the following criteria:
n
Sort all routers in the Node Group alphabetically by name and choose the first one in the list
n
If no routers are in the Node Group, sort all nodes in the Node Group alphabetically by name and
choose the first one in the list.
l
Island Node Groups are identified using "Island" in the Node Group Name. NNMi also assigns each
Island Node Group name a number to ensure the name is unique.
l
Island Node Groups are manage internally. Therefore, NNMi administrators should not modify Island
Node Group configurations. NNMi overrides any user changes the next time NNMi updates the Island
Node Group discovery information.
l
Island Node Groups must have at least two nodes.
l
How the Status of Island Node Groups is calculated cannot be changed.
Page 209 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
The only possible Status values for Island Node Groups are Unknown and Normal. Unknown indicates
that NNMi cannot reach any nodes in the group. Normal indicates that NNMi can reach at least one node
in the group.
Related Topics
"Node Groups As Predefined View Filters" (on page 207)
Interface Groups Provided by NNMi
NNMi Provides the following Interface Groups as predefined view filters. These Interface Groups can also
be used for Monitoring Configuration if you find them useful.
Feel free to populate these Interface Groups with specific information about your management domain and
change them to meet your needs.
Interface Groups Provided by NNMi
Name
Purpose
ISDN
Interfaces
This Interface Group includes multiple interface types known to be commonly used for
ISDN purposes. Any interface within your management domain that meets the defined
criteria is automatically included in this Interface Group.
Link
Aggregation
NNMi Advanced. This Interface Group includes all of the Link Aggregation Aggregator
Interfaces discovered in the network. See Layer 2 Neighbor View Map Objects for more
information about Aggregator Interfaces.
Use Actions → Show Members to identify the Link Aggregation Aggregator Interfaces in
this group.
Point to
Point
Interfaces
This Interface Group includes multiple interface types known to be commonly used for
point-to-point purposes. Any interface within your management domain that meets the
defined criteria is automatically included in this Interface Group.
Software
Loopback
Interfaces
This Interface Group includes any interface that is IfType 24, software loopback from the
IANA ifType-MIB. Any interface within your management domain that meets this loopback
address1 criteria is automatically included in this Interface Group.
VLAN
Interfaces
This Interface Group includes interfaces of ifType l2vlan. The NNMi default Monitoring
Configuration settings enable fault monitoring for these interfaces, but disable
performance monitoring (because collection of performance data for VLAN interfaces
tends to be problematic).
Voice
Interfaces
This Interface Group includes multiple interface types known to be commonly used for
voice purposes. Any interface within your management domain that meets the defined
criteria is automatically included in this Interface Group.
1The address associated with the loopback interface. The loopback interface is a virtual interface on a
device that provides a route for internal communication. Many vendors provide a specially configured
loopback for management purposes. Exact details of how loopbacks are configured varies by vendor and
model. See each device's documentation for details. NNMi identifies these loopback addresses by using
IfType 24, softwareloopback from the IANA ifType-MIB.
Page 210 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Add Custom Attributes to a Node or Interface Object
If you determine that you want to keep track of additional information about a node or interface, you can
add Custom Attributes to these objects. For example, you might determine that you want to track the owner
of your nodes on the network. You might also want to track the serial number for each node.
Tip: When defining Node Group definitions or Interface Group definitions, you can use the Additional
Filters' customAttrName/customAttrValue pairs and the EXISTS expression as a filter for
membership in the group.
Custom attributes can be created in two ways:
l
Open a particular Node form or Interface form (see below).
l
Use the nnmloadattributes.ovpl command line tool to "Add Custom Attributes to Multiple Nodes or
Interfaces" (on page 212).
To add Custom Attributes to a node object:
1. Navigate to the Custom Attributes tab:
a. From the workspace navigation panel, select a workspace that contains a Node view. For
example, the Inventory workspace.
b. Click the
Open icon in the row representing the node with settings you want to edit.
c. Select the Custom Attributes tab.
2. Click the
New icon to create a Custom Attribute.
3. Enter a Name and Value. See Node Custom Attributes Form for more information.
4. Click
Save and Close to return to the main Node Form.
5. Click
Save and Close to save your changes.
To add Custom Attributes to an interface object:
1. Navigate to the Custom Attributes tab:
a. From the workspace navigation panel, select a workspace that contains an Interfaces view.
For example, the Inventory workspace.
b. Click the
Open icon in the row representing the interface with settings you want to edit.
c. Select the Custom Attributes tab.
2. Click the
New icon to create a Custom Attribute.
3. Enter a Name and Value. See Interface Custom Attributes Form for more information.
4. Click
Save and Close to return to the main Interface Form.
5. Click
Save and Close to save your changes.
Page 211 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Creating Groups of Nodes or Interfaces
Add Custom Attributes to Multiple Nodes or Interfaces
Tip: When defining Node Group definitions or Interface Group definitions, you can use the Additional
Filters' customAttrName/customAttrValue pairs and the EXISTS expression as a filter for
membership in the group.
Custom attributes can be created in two ways:
l
Open a particular Node form or Interface form, and use the
New button to add one (see "Add
Custom Attributes to a Node or Interface Object" (on page 211)).
l
Use the nnmloadattributes.ovpl command line tool to add Custom Attributes to multiple Nodes (see
below),
The nnmloadattributes.ovpl command line tool enables you to load Custom Attributes from a commaseparated values (CVS) file. This feature is useful if you have information about a large number of nodes
or interfaces defined in an external data storage, and you would like to load that information into the NNMi
database as Custom Attributes. For example:
l
Node location information in a Microsoft Excel spreadsheet where you track the location of each node:
You can save this information as a .csv file. Use the nnmloadattributes.ovpl command to define
BldgLocation as a Custom Attribute and load the location values for each node into the NNMi
database. You can then create a Node Group with an Additional Filters specification using
BldgLocation as the customAttrName and the location of interest, such as Building Five Upper as the
customAttrValue.
l
Interface information in a comma-separated value file where you track the name of customers assigned
to each interface: Use the nnmloadattributes.ovpl command to define Customer as a Custom
Attribute and load the name values for each customer into the NNMi database. You can then create an
Interface Group with an Additional Filters specification using Customer as the customAttrName and a
customer name, such as Hewlett Packard as the customAttrValue.
To load Custom Attributes for Nodes or Interfaces using a comma-separated file:
See the nnmloadattributes.ovpl Reference Page for more information about the
nnmloadattributes.ovpl command, including requirements for the CSV file. You must provide a CSV
file with a specific syntax and order. Each column in the CSV file has a pre-defined meaning.
nnmloadattributes.ovpl -u <NNMiadminUsername> -p <NNMiadminPassword> -r
[true|false] -t node -f <CSV file name>
-r true = the value of any existing Custom Attribute with the same customAttrName is overwritten with
the value in your CSV file. The default setting is -r false = if the customAttrName already exists, the
nnmloadnodegroups.ovpl command does not change the previous customAttrValue.
-t is used to specify the object type on which the attributes should be loaded. Use node to load Custom
Attribute information for nodes.
CSV file name is the name of the CSV file that contains the Node Custom Attribute information.
Page 212 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Monitoring Network Health
Note: If you are using NNMi Advanced, also see "Monitor Router Redundancy Groups (NNMi Advanced)"
(on page 244).
Before NNMi can monitor the health of your network, the following tasks must be completed:
l
"Configuring Communication Protocol" (on page 66)
l
"Discovering Your Network" (on page 112)
For the most flexibility, also complete these tasks:
l
Review the "Interface Groups Provided by NNMi" (on page 210) and "Node Groups Provided by NNMi"
(on page 207).
l
Create your own groups by "Creating Groups of Nodes or Interfaces" (on page 179).
The State Poller and the Causal Engine work together to automatically monitor the health of your network.
Many of the tasks you normally do to troubleshoot network problems are now automated. To learn more
about how this works, see the following topics:
l
"About the State Poller" (on page 213)
l
"The NNMi Causal Engine and Monitoring" (on page 214)
You control which network devices NNMi monitors. By monitoring only the devices that are important
within your network environment, you keep the amount of traffic generated by NNM to a minimum. You can
configure NNMi to check devices with status other than critical less frequently (if at all) to prevent
unimportant incidents from showing up in the Incident views.
To configure the polling policies that control how NNMi monitors devices in your network, see "Configure
Monitoring Behavior" (on page 214). You can configure NNMi monitoring behavior to meet your needs.
About the State Poller
The State Poller Service monitors each discovered interface, address, and SNMP agent that is designated
to be actively monitored in your management domain. State Poller can also be configured to provide Node
Component monitoring and Router Redundancy Group monitoring.
State Poller gathers information in the following area and updates the State field on each object's form:
l
Verifies that each monitored IP Address is responding to ICMP ping.
l
Verifies that each monitored SNMP Agent is responding to SNMP queries.
l
Issues an SNMP query for the following:
l
n
Each monitored interface, requesting the current value for MIB II ifAdminStatus and ifOperStatus.
(ifAdminStatus is set by the device administrator. ifOperStatus indicates the operational status of
interface health.)
n
Router Redundancy Groups.
n
Node Component data.
By default, State Poller monitors interfaces connected to another known interface through a Layer 2
connection.
Page 213 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
You can extend monitoring to include the following:
l
n
Unconnected interfaces
n
Interfaces that have an IP address (for example a router interface that services mobile laptop
machines)
n
(HP Network Node Manager iSPI Performance for Metrics Software). The State Poller also collects
performance data and monitors thresholds. See "Purchase an HP Network Node Manager i Smart
Plug-in" (on page 950).
The State Poller stores the results of the queries in the NNMi database and notifies the Causal Engine of
any changes. The Causal Engine gathers additional information about the overall health of each interface
and SNMP agent. Using this information the Causal Engine calculates the Status of each node, interface,
and SNMP agent (see "The NNMi Causal Engine and Monitoring" (on page 214) for more information).
To configure the behavior of the State Poller, see "Configure Monitoring Behavior" (on page 214).
The NNMi Causal Engine and Monitoring
The Causal Engine actively gathers information about your network devices from incoming incidents and
traps. The Causal Engine also uses the data gathered by State Poller and by Discovery to calculate the
current health status of each node, interface, IP address, SNMP agent, and connection.
The health status is dynamic (based on what the environment looks like now).
The NNMi Causal Engine communicates device health information in the following ways:
l
In the database, the Causal Engine stores a multitude of information about each device. You can
access this information in the Node, Interface, IP Address, SNMP Agent, and connection forms.
l
On the maps, the color of the background shape for each map icon changes to the color that
represents the most currently calculated health status, based on the Causal Engine calculations for
that node, interface, address, or connection (click here for information about status colors).
l
On forms for Nodes, Interfaces, IP addresses, SNMP Agents, and connections, the Causal Engine
updates the Status attribute to show the current status:
Critical,
Unknown, or
No Status.
l
Normal,
Warning,
Minor,
Major,
The Status column in table views is updated.
The Causal Engine also uses health status information to determine root cause. See "The NNMi Causal
Engine and Incidents" (on page 306) for more information about the Causal Engine, incidents, and root
cause analysis.
Configure Monitoring Behavior
Certain devices in your network are the most important ones. You and your team must keep those devices
up and running at all times. Adjust NNMi monitoring behavior to focus on the important devices and to
check devices with status other than critical less frequently (if at all).
Note: NNMi does not poll any private interface, IPv4 Anycast Rendezvous Point IP Address 1 or IPv6
Anycast address.
1Rendezvous Point addresses are loopback addresses used for routers in multi-cast network
configurations.
Page 214 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Based on your individual situation, adjust the NNMi behavior to meet your needs. NNMi applies your
Monitoring Configuration settings in the following sequence:
1. Interface Settings: NNMi monitors each of the Node's Interfaces and IP Addresses based on the first
matching Interface Settings definition. The first match is the Interface Settings definition with the
lowest Ordering number.
2. Node Setting: NNMi monitors each Node and each previously unmatched Interface or IP Address
based on the first matching Node Settings definition. The first match is the Node Settings definition
with the lowest Ordering number.
Note: Child node groups are included in the Ordering hierarchy. This means that if the parent node
group has a lower Ordering number (for example, parent=10, child=20), then the monitoring
configuration specified for the parent node group also applies to the nodes in the child node
group. To override a parent node group monitoring configuration, set the Ordering number for
the child node group to a number that is lower than the parent (for example, parent=20,
child=10).
3. Default Settings: If no match is found for a Node, Interface, or IP Address in 1 or 2, NNMi applies the
default Monitoring Configuration settings.
Tasks for Configuring the Monitoring Behavior
Task
How
"Set Global Monitoring" (on page 215). Optional. Use the Global Control group.
"Set Default Monitoring" (on page
217).
Use the Default Settings tab to establish monitoring behavior for
any devices that are discovered, but not included in any Node
Settings or Interface Settings definitions.
"Configure Node Monitoring" (on page
232)
Optional. Use the Node Settings tab. Configure settings based
on Node Groups to customize the way NNMi monitors certain
groups of devices in your environment.
Prerequisite: "Create Node Groups" (on page 179).
Fine tune behavior for specific types of
Interfaces,see "Configure Interface
Monitoring" (on page 221) .
Optional. Use the Interface Settings tab. Configure settings
based on Interface Groups to customize the way NNMi monitors
certain interface types in your environment.
Prerequisite: "Create Interface Groups" (on page 195).
Detect Interface Changes
Optional. Use Device Profiles to configure how to detect
interface changes.
Set Global Monitoring
Note: To suspend all SNMP traffic generated by NNMi, rather than only the State Poller Service SNMP
traffic, see "Communication Region Form" (on page 80) and "Specific Node Settings Form
(Communication Settings)" (on page 96).
To temporarily turn off all NNMi monitoring activity without tampering with your customized
monitoring configuration settings:
Page 215 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
1. Navigate to the Monitoring Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Monitoring Configuration.
2. Locate the Global Control group box.
3. Clear the check box preceding each setting that you want to disable or set the
preceding each setting that you want to enable(see table).
check box
4. Click
Save and Close. NNMi applies your changes. The next regularly scheduled monitoring
cycle uses the new settings.
To verify that State Poller is working as expected, see the report on the State Poller tab in Help →
System Information.
Global Control
Name
Description
Enable State
Polling
If enabled, State Poller monitors all managed objects (for example, interfaces, IP
addresses, and SNMP agents) by issuing ICMP pings and SNMP read-only queries for
MIB II ifAdminStatus and ifOperStatus. (ifAdminStatus is set by the device administrator.
ifOperStatus indicates the overall health of the device and is supplied by the SNMP
Agent.) You can also configure NNMi so that State Poller gathers additional information
about Node Components and Router Redundancy Groups.
If
Enable Card
Polling
disabled:
l
Previously discovered devices remain with the last calculated state/status.
l
Newly discovered devices are set to "No Status" with map-symbol background shape
color set to beige.
If enabled, State Poller monitors all managed cards. See Card Form for more
information about card metrics.
Note: Card monitoring is enabled by default.
If
Enable
Node
Component
Polling
disabled:
l
Previously discovered cards are assigned a State of Not Polled and a Status of No
Status for Card metrics.
l
Newly discovered cards are assigned a State of Not Polled and a Status of No
Status.
If enabled, State Poller monitors Node Component metrics for all managed nodes. See
Node Form: Node Component Tab for more information about Node Component metrics.
Note: Node Component monitoring is enabled by default.
If
disabled:
l
Previously discovered devices are assigned a State of Not Polled and a Status of No
Status for Node Component metrics.
l
Node Component metrics for newly discovered devices are assigned a State of Not
Polled and a Status of No Status.
Page 216 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Name
Description
Enable
Router
Redundancy
Group
Polling
(NNMi
Advanced)
If enabled, NNMi monitors all managed Router Redundancy Groups. See Router
Redundancy Group View (NNMi Advanced) for more information about Router
Redundancy Groups.
Note: Router Redundancy Group monitoring is enabled by default.
If
disabled:
l
Previously discovered Router Redundancy Groups are assigned a State of Not
Polled and a Status of No Status.
l
Newly discovered Router Redundancy Groups are assigned a State of Not Polled
and a Status of No Status.
Set Default Monitoring
The choices you make for "defaults" apply only to devices with interfaces, IP addresses, cards, SNMP
agents (Management Addresses), Tracked Objects, Router Redundancy Groups, or Node Component
monitoring settings that are not covered by any Interface Settings or Node Settings definitions.
To establish default NNMi monitoring behavior:
1. Navigate to the Defaults Settings tab.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Monitoring Configuration.
c. Locate the Defaults Settings tab.
2. Locate the Default Fault Monitoring group box.
3. Configure the Default Fault Monitoring behavior (see Default Fault Monitoring table).
4. (HP Network Node Manager iSPI Performance for Metrics Software) If the HP Network Node
Manager iSPI Performance for Metrics Software is installed, locate the Default Performance
Monitoring group box.
Configure the Default Performance Monitoring behavior (see the Default Fault Monitoring table and
Default Performance Monitoring table).
5. By default, NNMi monitors only interfaces that are connected to other interfaces. When SNMP polling
is enabled, NNMi automatically detects most connections. See "Add or Delete a Layer 2 Connection"
(on page 174) for information about manual overrides.
Optional. If you want to expand default monitoring behavior to include unconnected Interfaces,
indicate your choices in the Default Extend the Scope of Polling Beyond Connected Interfaces group
box
6. Optional. To establish custom monitoring behavior for one or more groups of interfaces, configure
Interface Settings, see "Configure Interface Monitoring" (on page 221).
7. Optional. To establish custom monitoring behavior for one or more groups of nodes, configure Node
Settings, see "Configure Node Monitoring" (on page 232).
8. Click
Save and Close. NNMi applies your changes. The next regularly scheduled monitoring
cycle uses the new settings.
Page 217 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
To verify that State Poller is working as expected, see the report on the State Poller tab in Help →
System Information.
Default Fault Monitoring (choose one or none)
Attribute
Description
Enable ICMP
Management Address
Polling
If enabled, State Poller only issues ICMP (ping) requests to IP addresses
classified as management addresses in the NNMi database. Note: In the
Global Control section of the Monitoring Configuration form, the Enable State
Polling attribute must be enabled, too.
If
disabled, State Poller does one of the following:
l
If neither this attribute nor Enable ICMP Fault Polling is selected, State
Poller does not use ICMP to monitor nodes covered by this configuration
setting.
l
If Enable ICMP Fault Polling is selected, State Poller uses ICMP to monitor
ALL IP addresses covered by this configuration setting.
Changing the default monitoring settings for the management addresses takes
effect immediately. To verify the change, see "Verify Monitoring Configuration
Settings" (on page 244).
Enable ICMP Fault
Polling
Note: This monitoring
option is useful for
devices that do not
support SNMP. By
default, this feature is
enabled for the "NonSNMP Devices" Node
Group.
If enabled, State Poller issues ICMP (ping) requests to verify the availability
of discovered IP address. Note: In the Global Control section of this form, the
Enable State Polling attribute must be enabled, too.
If
disabled, State Poller does the following:
l
If neither this attribute nor Management IP Address Polling is selected,
State Poller does not use ICMP to monitor nodes covered by this
configuration setting.
l
IP addresses (both previously discovered and newly discovered) have a
State attribute value of "Not Polled" and a Status attribute value of "No
Status" with the color of the IP address map-symbol set to beige. See Layer
3 Neighbor View.
l
If both ICMP and SNMP are disabled for a Node, the Node has a Status
attribute value of "No Status" and the color of the Node map-symbol
background shape is set to beige.
Tip: To turn off ICMP polling within a subset of your network environment, use
the Communication Configuration workspace Region definitions. You can
define your own Regions that identify any unreachable addresses in your
management domain (for example, the private IP addresses 1).
Enable SNMP Interface
Fault Polling
If enabled, State Poller monitors all interfaces by issuing SNMP read-only
queries to devices assigned to this level of the monitoring hierarchy.
By default, any connected interface is monitored for MIB II ifAdminStatus and
ifOperStatus. (ifAdminStatus is set by the device administrator. ifOperStatus
indicates the operational status of interface health.) If you have unconnected
1These are IPv4 addresses that can be reused in home and office local area networks (LANs). Following
the standards set by RFC 1918 and RFC 4193 (10.*.*.*, 169.254.*.*, 172.16-31.*.*, and 192.168.*.*)
Page 218 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
interfaces that you want to monitor, expand NNMi monitoring behavior with the
Poll Unconnected Interfaces and the Poll Interfaces Hosting IP Addresses
attributes.
Note: The following attributes must also be enabled:
l
In the Global Control section of this form, the Enable State Polling attribute
must be enabled, too. See Layer 2 Neighbor View. (See "Set Global
Monitoring" (on page 215) for more information.)
l
In the Communication Configuration view, enable State Poller queries with
the applicable Enable SNMP Communication attributes (see "Configuring
Communication Protocol" (on page 66) for more information).
If
Enable Card Fault
Polling
disabled, for devices assigned to this level of the monitoring hierarchy:
l
Causal Engine calculates Status based only on IP address State.
l
The Interface objects previously discovered change to a State attribute
value of "Not Polled" and a Status attribute value of "No Status" (plus any
related map-symbol changes to a beige color).
Use this attribute to poll fault metrics for cards. Card fault metrics include
Administrative State, Operational State, and Standby State.
Note: Card Fault Polling is enabled by default.
If enabled, NNMi gathers fault data related to the card fault metrics in
devices assigned to this level of the monitoring hierarchy.
If disabled, NNMi does not extend data collection behavior to include card
fault data about devices assigned to this level of the monitoring hierarchy.
Note: NNMi uses the same polling interval set for the Fault Polling Interval.
Enable Node
Component Fault
Polling
Note: By default, this
feature is enabled for
the "Routers" and
"Networking
Infrastructure Devices"
Node Groups.
Use this attribute to poll Node Component fault metrics. Node Component fault
metrics include the following: Fan, Power Supply, Temperature, and Voltage.
Note: Node Component Fault Polling is disabled by default.
If enabled, NNMi gathers fault data related to the Node Component fault
metrics in devices assigned to this level of the monitoring hierarchy.
If disabled, NNMi does not extend data collection behavior to include Node
Component fault data about devices assigned to this level of the monitoring
hierarchy.
Note: NNMi uses the same polling interval set for the Fault Polling Interval.
Page 219 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Fault Polling Interval
The time that State Poller waits between issuing queries to gather information
for any of the following that are enabled: ICMP Polling, SNMP Polling, Poll
Unconnected Interfaces, and Poll Interfaces Hosting IP addresses.
Note: NNMi monitors SNMP agents (Management Addresses) according to
this Fault Polling Interval, even if ICMP Polling, SNMP Polling, Poll
Unconnected Interfaces, and Poll Interfaces Hosting IP addresses are
all disabled. To prevent an SNMP Agent's address from being
monitored, one of the following must be true: State Polling is disabled,
current Communication Configuration settings turn off SNMP for the
SNMP agent's address, or the parent Node is set to Not Managed or Out
of Service.
Default Performance Monitoring (HP Network Node Manager iSPI Performance for Metrics
Software)
Attribute
Description
Enable SNMP
Interface
Performance Polling
(HP Network Node Manager iSPI Performance for Metrics Software) Use this
attribute to extend the range of polling data that NNMi collects. HP Network
Node Manager iSPI Performance for Metrics Software uses the additional data
in a series of performance reports. See "Purchase an HP Network Node
Manager i Smart Plug-in" (on page 950) for more information. When enabled,
network traffic increases on your network because NNMi gathers performance
data about each member of this group on a regular schedule.
If enabled, NNMi gathers performance data from Interfaces, CPU, memory,
and buffers in devices assigned to this level of the monitoring hierarchy.
If disabled, NNMi does not extend data collection behavior to include
performance data about devices assigned to this level of the monitoring
hierarchy.
Note: The Enable State Polling field must be enabled, too. By default the
performance of connected interfaces and addresses is monitored. If you
have unconnected interfaces that you want to monitor, expand NNMi
monitoring behavior by enabling Poll Unconnected Interfaces.
Enable Node
Component
Performance Polling
Note: By default, this
feature is enabled for
the "Routers" Node
Group if HP Network
Node Manager iSPI
Performance for
Metrics Software is
installed.
(HP Network Node Manager iSPI Performance for Metrics Software) Use this
attribute to poll Node Component performance. An NNMi administrator can set
the threshold for node components related to the following performance metrics:
CPU utilization, memory utilization, buffer utilization, buffer miss rate, and buffer
failure rate.
Note: Node Component Performance Polling is disabled by default.
If enabled, NNMi gathers performance data related to the Node Component
performance metrics in devices assigned to this level of the monitoring
hierarchy.
If disabled, NNMi does not extend data collection behavior to include Node
Component performance data about devices assigned to this level of the
monitoring hierarchy.
Note: NNMi uses the same polling interval set for the Performance Polling
Interval.
Page 220 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Performance Polling
Interval
(HP Network Node Manager iSPI Performance for Metrics Software) Use this
field to set the time period that NNMi waits between issuing network traffic to
gather performance data for the HP Network Node Manager iSPI Performance
for Metrics Software.
Default Extend the Scope of Polling Beyond Connected Interfaces
Attribute
Description
Poll Unconnected
Interfaces
If enabled, NNMi monitors all interfaces within discovered devices (both
connected and unconnected). All interfaces are monitored for MIB II ifAdminStatus
and ifOperStatus. (ifAdminStatus is set by the device administrator. ifOperStatus
indicates the operational status of interface health.) Note: The Enable State
Polling field must be enabled, and SNMP polling of some type must be enabled
(for example, Enable SNMP Fault Monitoring and Enable SNMP Performance
Polling).
If
disabled, State Poller polls according to other configuration settings.
Tip: Your discovery configuration choices may need to be adjusted to get the
results you want. For example, to meet the “connected” criteria for interfaces in
switches that do not have an IP address you must add the device to which the
interface is connected as a discovery seed. See"Discovery Seeds (as a starting
point)" (on page 118).
Poll Interfaces
Hosting IP
Addresses
Note: This
monitoring option is
useful for Router
interfaces. By
default, this feature
is enabled for the
"Routers" Node
Group.
If enabled, any unconnected interface that has one or more addresses
associated with it is monitored for MIB II ifAdminStatus and ifOperStatus.
(ifAdminStatus is set by the device administrator. ifOperStatus indicates the
operational status of interface health.) Note: The Enable State Polling field must
be enabled, and SNMP polling of some type must be enabled (for example,
Enable SNMP Fault Monitoring and Enable SNMP Performance Polling).
By monitoring the Interface (in addition to the IP address), NNMi can make more
informed decisions about the health of each IP address associated with an
unconnected interface.
If
disabled, State Poller polls according to other configuration settings.
Tip: The Communication Configuration workspace provides a method of
overriding this setting for specific Regions. You can define your own Region to
easily turn off polling to any unreachable addresses in your management
domain (for example, the private IP addresses 1).
Configure Interface Monitoring
Before you start, you must establish one or more Interface Group definitions that identify the interface types
to which these monitoring settings will apply. NNMi provides nearly 250 interface types to choose from.
1These are IPv4 addresses that can be reused in home and office local area networks (LANs). Following
the standards set by RFC 1918 and RFC 4193 (10.*.*.*, 169.254.*.*, 172.16-31.*.*, and 192.168.*.*)
Page 221 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Interface monitoring applies to matching interfaces and the IP addresses that are hosted on those
interfaces. See also, "Interface Groups Provided by NNMi" (on page 210).
To establish monitoring behavior for one or more predefined Interface Groups:
1. Navigate to the Interface Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Monitoring Configuration.
c. Locate the Interface Settings tab.
d. Do one of the following:
o To create an Interface Settings definition, click the
o To edit an Interface Settings definition, click the
New icon.
Open icon in the row representing the
Interface Settings definition you want to edit.
o To delete an Interface Settings definition, select a row and click the
Delete button
2. Establish the appropriate settings to identify this Interface Setting definition (see Basics table).
3. Optional. Configure the Fault Monitoring behavior for this Interface Setting definition (see Fault
Monitoring table).
4. (HP Network Node Manager iSPI Performance for Metrics Software) If the HP Network Node
Manager iSPI Performance for Metrics Software software is installed:
n
Configure the Performance Monitoring behavior for this Interface Setting definition (see
Performance Monitoring table).
n
Optional. Navigate to the Threshold Settings tab to configure the HP Network Node Manager iSPI
Performance for Metrics Software software. See "Configure Threshold Monitoring for Interfaces
(HP Network Node Manager iSPI Performance for Metrics Software)" (on page 226) for more
information.
5. By default, NNMi monitors only interfaces that are connected to other interfaces. When SNMP polling
is enabled, NNMi automatically detects most connections. See "Add or Delete a Layer 2 Connection"
(on page 174) for information about manual overrides.
Optional. If you want to expand monitoring behavior for this group to include unconnected Interfaces,
indicate your choices in the Extend the Scope of Polling Beyond Connected Interfaces group box.
6. Click
Save and Close to return to the Monitoring Configuration form.
7. Click
Save and Close. NNMi applies your changes. The next regularly scheduled monitoring
cycle uses the new settings.
Caution: When you establish monitoring configuration settings, NNMi must recalculate membership
in all Node Groups and Interface Groups. This can take some time and slow down your
system. Consider making this change during a slow time in your network environment.
To verify that State Poller is working as expected, see the report on the State Poller tab in Help →
System Information.
Optional. Customize the node monitoring behavior. See "Configure Node Monitoring" (on page 232) . Also
see "Detect Interface Changes (renumbering issues)" (on page 172)
Page 222 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Basics
Attribute
Description
Ordering
Enter a unique string (any length), characters 0 through 9. Consider using increments of 100
for the flexibility to insert additional items between existing items over time.
NNMi decides which monitoring configurations apply to a node or interface based on the
ordering number assigned to the configuration definitions. NNMi monitors the device
according to the first match (checked from lowest number to highest number within each
category). Categories are read in sequence. Click here for a description of the sequence.
1. Interface Settings: NNMi monitors each of the Node's Interfaces and IP Addresses
based on the first matching Interface Settings definition. The first match is the Interface
Settings definition with the lowest Ordering number.
2. Node Setting: NNMi monitors each Node and each previously unmatched Interface or
IP Address based on the first matching Node Settings definition. The first match is the
Node Settings definition with the lowest Ordering number.
Note: Child node groups are included in the Ordering hierarchy. This means that if the
parent node group has a lower Ordering number (for example, parent=10,
child=20), then the monitoring configuration specified for the parent node group
also applies to the nodes in the child node group. To override a parent node
group monitoring configuration, set the Ordering number for the child node group
to a number that is lower than the parent (for example, parent=20, child=10).
3. Default Settings: If no match is found for a Node, Interface, or IP Address in 1 or 2,
NNMi applies the default Monitoring Configuration settings.
No duplicate Ordering numbers are allowed. Each Interface Setting ordering number must be
unique.
Interface
Group
Choose one predefined Interface Group from the list. See "Create Interface Groups" (on page
195) for more information.
(NNMi Advanced with IPv6 enabled) See also "Interface Groups of IPv4 or IPv6 Addresses "
(on page 204).
Fault Monitoring
Attribute
Description
Enable ICMP If enabled, State Poller only issues ICMP (ping) requests to IP addresses classified as
Management management addresses in the NNMi database. Note: In the Global Control section of the
Address
Monitoring Configuration form, the Enable State Polling attribute must be enabled, too.
Poling
If disabled, State Poller does one of the following:
l
If neither this attribute nor Enable ICMP Fault Polling is selected, State Poller does
not use ICMP to monitor nodes covered by this configuration setting.
l
If Enable ICMP Fault Polling is selected, State Poller uses ICMP to monitor ALL IP
addresses covered by this configuration setting.
Page 223 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Enable ICMP
Fault Polling
If enabled, State Poller issues ICMP (ping) requests to verify the availability of
discovered IP address. Note: In the Global Control section of this form, the Enable State
Polling attribute must be enabled, too.
Note: This
monitoring
option is
useful for
devices that
do not
support
SNMP.
If
disabled, State Poller does the following:
l
If neither this attribute nor Management IP Address Polling is selected, State Poller
does not use ICMP to monitor nodes covered by this configuration setting.
l
IP addresses (both previously discovered and newly discovered) have a State
attribute value of "Not Polled" and a Status attribute value of "No Status" with the color
of the IP address map-symbol set to beige. See Layer 3 Neighbor View.
l
If both ICMP and SNMP are disabled for a Node, the Node has a Status attribute
value of "No Status" and the color of the Node map-symbol background shape is set
to beige.
Tip: To turn off ICMP polling within a subset of your network environment, use the
Communication Configuration workspace Region definitions. You can define your
own Regions that identify any unreachable addresses in your management domain
(for example, the private IP addresses 1).
Enable
SNMP
Interface
Fault Polling
If enabled, State Poller monitors all interfaces by issuing SNMP read-only queries to
devices assigned to this level of the monitoring hierarchy.
By default, any connected interface is monitored for MIB II ifAdminStatus and
ifOperStatus. (ifAdminStatus is set by the device administrator. ifOperStatus indicates the
operational status of interface health.) If you have unconnected interfaces that you want
to monitor, expand NNMi monitoring behavior with the Poll Unconnected Interfaces and
the Poll Interfaces Hosting IP Addresses attributes.
Note: The following attributes must also be enabled:
l
In the Global Control section of this form, the Enable State Polling attribute must be
enabled, too. See Layer 2 Neighbor View. (See "Set Global Monitoring" (on page
215) for more information.)
l
In the Communication Configuration view, enable State Poller queries with the
applicable Enable SNMP Communication attributes (see "Configuring
Communication Protocol" (on page 66) for more information).
If
Fault Polling
Interval
disabled, for devices assigned to this level of the monitoring hierarchy:
l
Causal Engine calculates Status based only on IP address State.
l
The Interface objects previously discovered change to a State attribute value of "Not
Polled" and a Status attribute value of "No Status" (plus any related map-symbol
changes to a beige color).
The time that State Poller waits between issuing queries to gather information for any of
the following that are enabled: ICMP Polling, SNMP Polling, Poll Unconnected Interfaces,
and Poll Interfaces Hosting IP addresses.
Note: NNMi monitors SNMP agents (Management Addresses) according to this Fault
1These are IPv4 addresses that can be reused in home and office local area networks (LANs). Following
the standards set by RFC 1918 and RFC 4193 (10.*.*.*, 169.254.*.*, 172.16-31.*.*, and 192.168.*.*)
Page 224 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Polling Interval, even if ICMP Polling, SNMP Polling, Poll Unconnected Interfaces,
and Poll Interfaces Hosting IP addresses are all disabled. To prevent an SNMP
Agent's address from being monitored, one of the following must be true: State
Polling is disabled, current Communication Configuration settings turn off SNMP
for the SNMP agent's address, or the parent Node is set to Not Managed or Out of
Service.
Performance Monitoring (HP Network Node Manager iSPI Performance for Metrics Software)
Attribute
Description
Enable
SNMP
Interface
Performance
Polling
(HP Network Node Manager iSPI Performance for Metrics Software) Use this attribute to
extend the range of polling data that NNMi collects. HP Network Node Manager iSPI
Performance for Metrics Software uses the additional data in a series of performance
reports. See "Purchase an HP Network Node Manager i Smart Plug-in" (on page 950) for
more information. When enabled, network traffic increases on your network because
NNMi gathers performance data about each member of this group on a regular schedule.
If enabled, NNMi gathers performance data from Interfaces, CPU, memory, and buffers
in devices assigned to this level of the monitoring hierarchy.
If disabled, NNMi does not extend data collection behavior to include performance
data about devices assigned to this level of the monitoring hierarchy.
Note: The Enable State Polling field must be enabled, too. By default the performance of
connected interfaces and addresses is monitored. If you have unconnected
interfaces that you want to monitor, expand NNMi monitoring behavior by enabling
Poll Unconnected Interfaces.
Performance
Polling
Interval
(HP Network Node Manager iSPI Performance for Metrics Software) Use this field to set
the time period that NNMi waits between issuing network traffic to gather performance
data for the HP Network Node Manager iSPI Performance for Metrics Software.
Extend the Scope of Polling Beyond Connected Interfaces
Attribute
Description
Poll
Unconnected
Interfaces
If enabled, NNMi monitors all interfaces within discovered devices (both connected
and unconnected). All interfaces are monitored for MIB II ifAdminStatus and ifOperStatus.
(ifAdminStatus is set by the device administrator. ifOperStatus indicates the operational
status of interface health.) Note: The Enable State Polling field must be enabled, and
SNMP polling of some type must be enabled (for example, Enable SNMP Fault
Monitoring and Enable SNMP Performance Polling).
If
disabled, State Poller polls according to other configuration settings.
Tip: Your discovery configuration choices may need to be adjusted to get the results you
want. For example, to meet the “connected” criteria for interfaces in switches that do
not have an IP address you must add the device to which the interface is connected
as a discovery seed. See"Discovery Seeds (as a starting point)" (on page 118).
Page 225 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Poll
Interfaces
Hosting IP
Addresses
If enabled, any unconnected interface that has one or more addresses associated
with it is monitored for MIB II ifAdminStatus and ifOperStatus. (ifAdminStatus is set by the
device administrator. ifOperStatus indicates the operational status of interface health.)
Note: The Enable State Polling field must be enabled, and SNMP polling of some type
must be enabled (for example, Enable SNMP Fault Monitoring and Enable SNMP
Performance Polling).
Note: This
monitoring
option is
useful for
Router
interfaces.
By monitoring the Interface (in addition to the IP address), NNMi can make more
informed decisions about the health of each IP address associated with an unconnected
interface.
If
disabled, State Poller polls according to other configuration settings.
Tip: The Communication Configuration workspace provides a method of overriding this
setting for specific Regions. You can define your own Region to easily turn off polling
to any unreachable addresses in your management domain (for example, the private
IP addresses1).
Configure Threshold Monitoring for Interfaces (HP Network Node Manager iSPI
Performance for Metrics Software)
Use the Threshold Settings form to configure NNMi and the HP Network Node Manager iSPI Performance
for Metrics Software to monitor thresholds in your network environment. (See "Purchase an HP Network
Node Manager i Smart Plug-in" (on page 950) for more information about the HP Network Node Manager
iSPI Performance for Metrics Software.) If you set thresholds, NNMi can generate an Incident when any
threshold is violated. Examples of the types of threshold you can set for an interface include the following:
(See Monitored Attributes in the table below for a complete list.)
l
Input and output utilization
l
Input and output error rates
l
Input and output discard rates
HP Network Node Manager iSPI Performance for Metrics Software provides exceptions reports to track the
frequency of threshold breaches. You can open these reports with Actions → Reporting - Report Menu in
the incident, node, or interface views and forms. (See HP Network Node Manager iSPI Performance for
Metrics Software Actions.)
To establish threshold monitoring behavior for the HP Network Node Manager iSPI Performance for
Metrics Software:
1. Prerequisite. After enabling Performance Monitoring for an Interface Group and before setting
thresholds, analyze performance data over time to determine wise threshold settings for each group.
See "Determine Reasonable Threshold Settings (HP Network Node Manager iSPI Performance for
Metrics Software)" (on page 229).
1These are IPv4 addresses that can be reused in home and office local area networks (LANs). Following
the standards set by RFC 1918 and RFC 4193 (10.*.*.*, 169.254.*.*, 172.16-31.*.*, and 192.168.*.*)
Page 226 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Note: When performance polling is enabled, network traffic increases on your network while NNMi
gathers performance data.
2. Navigate to the Thresholds Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Monitoring Configuration.
c. Navigate to the Interface Settings tab.
d. Do one of the following:
o To create an Interface Settings definition, click the
o To edit an Interface Settings definition, click the
New icon.
Open icon in the row representing the
Interface Settings definition you want to edit.
3. Verify that Performance Monitoring is enabled for this Interface Settings definition.
4. In the Interface Settings form, navigate to the Threshold Settings tab.
5. Do one of the following:
n
To create a threshold definition, click the
n
To edit a threshold definition, click the
definition you want to edit.
n
To delete a threshold definition, select a row and click the
New icon.
Open icon in the row representing the threshold
Delete icon.
6. Select the attribute you want to monitor and establish the threshold values for that attribute (see Basic
Threshold Settings table). For examples of setting meaningful thresholds, see "Examples of
Threshold Monitoring (HP Network Node Manager iSPI Performance for Metrics Software)" (on page
230).
7. Click
Save and Close to return to the Interface Settings form.
8. Click
Save and Close to return to the Monitoring Configuration form.
9. Click
Save and Close. NNMi applies your changes during the next regularly scheduled
monitoring cycle.
Note: Threshold Incidents are disabled by default within NNMi to prevent Incident storms. If you are
ready to generate Threshold Incidents, see "Generate Performance Threshold Incidents (HP
Network Node Manager iSPI Performance for Metrics Software)" (on page 422). See also
"Custom Incident Attributes Provided by NNMi (for Administrators)" (on page 310) for a
description of the special custom incident attributes available in Threshold Incidents.
To verify that State Poller is working as expected, see the report on the State Poller tab in Help →
System Information.
Basic Threshold Settings
Attribute
Description
Monitored
Attribute
NNMi gathers data to calculate thresholds for the following values. Click any item in this list
for more details about that value.
Note: NNMi also displays the Monitored Attributes that apply to nodes. See "Configure
Threshold Monitoring for Nodes (HP Network Node Manager iSPI Performance for
Metrics Software)" (on page 238) for more information about these attributes.
Page 227 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
l
Input Utilization
The total number of incoming octets traversing the interface as a percentage of the total
possible number of octets (based on the ifSpeed value). From Interface to Interface, the
exact MIB variables queried vary based on interface speed and whether the system
supports the high speed counters for interfaces.
Each interface in an Interface Groups has its utilization calculated by taking the total
traffic on all administratively up interfaces in the group and dividing that by the total
possible bandwidth.
Tip: To override the ifSpeed value returned by the device's SNMP agent, see the
Interface form.
l
Output Utilization
The total number of outbound octets traversing the interface as a percentage of the total
possible number of octets (based on the ifSpeed value). From Interface to Interface, the
exact MIB variables queried vary based on interface speed and whether the system
supports the high speed counters for interfaces.
Each interface in an Interface Group has its utilization calculated by taking the total
traffic on all administratively up interfaces in the group and dividing that by the total
possible bandwidth.
Tip: To override the ifSpeed value returned by the device's SNMP agent, see the
Interface form.
High
Value
l
Input Error Rate
Rate based on the reported change in the number of input packets on the interface and
the packet error count. What constitutes an error is system specific, but likely includes
such issues as bad packet checksums, incorrect header information, and runt packets.
l
Output Error Rate
Rate based on the reported change in the number of output packets on the interface
and the packet error count. What constitutes an error is system specific, but likely
includes such issues as collisions and buffer errors.
l
Input Discard Rate
Rate based on the reported change in the number of input packets on the interface and
the discarded packet count. Packets may be discarded because of a variety of issues,
including receive buffer overflows, congestion, or system specific issues.
l
Output Discard Rate
Rate based on the reported change in the number of output packets on the interface
and the discarded packet count. Packets may be discarded because of a variety of
issues, including transmission buffer overflows, congestion, or system specific issues.
Designate the percentage above which would indicate a value in the High range. Valid
entries are 0.00 through 100.00
Note: If you use 100.00 the threshold is disabled because it cannot be crossed.
Page 228 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
High
Value
Rearm
Designate the percentage that when reached would indicate the end of a high threshold
situation. Valid entries are 0.00 through 100.00
High
Trigger
Count
Designate the number of consecutive polling cycles in which the value must remain in the
High range before the threshold state changes to High.
Low
Value
The Low Value must be less than or equal to the High Value.
Note: The High Value Rearm must be less than or equal to the High Value and greater than
the Low Value Rearm.
Note: The interface performance values are the average value over the entire polling
interval, so a trigger count of 1 is usually appropriate.
Designate the percentage below which would indicate a value in the low range. Valid
entries are 0.00 through 100.00
Note: If you use 0.00 the threshold is disabled because it cannot be crossed.
Low
Value
Rearm
Designate the percentage that when reached would indicate the end of a low threshold
situation. Valid entries are 0.00 through 100.00.
Low
Trigger
Count
Designate the number of consecutive polling cycles in which the value must remain in the
Low range before the threshold state changes to Low.
Note: The Low Value Rearm must be greater than or equal to the Low Value and less than
the High Rearm Value.
Note: The interface performance values are the average value over the entire polling
interval, so a trigger count of 1 is usually appropriate.
Determine Reasonable Threshold Settings (HP Network Node Manager iSPI Performance for Metrics Software)
You must decide how to define normal behavior for devices in the associated Node Group or Interface
Group. You can then set reasonable thresholds for the group, and avoid Threshold Incident storms. See
"Examples of Threshold Monitoring (HP Network Node Manager iSPI Performance for Metrics Software)"
(on page 230).
Create a Node Group or Interface Group filter that includes the devices you want to monitor. Export the
Node Group or Interface Group filter to HP Network Node Manager iSPI Performance for Metrics Software.
See "Creating Groups of Nodes or Interfaces" (on page 179).
Enable Performance Monitoring for the Node Group or Interface Group. See "Configure Node Monitoring"
(on page 232) or "Configure Interface Monitoring" (on page 221). Then wait a minimum of 24 hours before
following the steps below.
Access the HP Network Node Manager iSPI Performance for Metrics Software Headline report:
1. In the NNMi console, click Actions → Reporting - Report Menu.
2. Click the link for Headline. The Headline report displays data from the past 24 hours from the time
you request the report. So if you run the report at 5.03 p.m., the report includes data since 5.03 p.m.
yesterday. Click the Help link in the report if you need information about how to use this report.
3. Open the Topology Filters panel and restrict your view to the network elements for which you are
determining thresholds.
Page 229 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
4. Click Confirm Selection to return to the report.
5. Open the Time Controls panel and select a start time and interval.
6. Click Confirm Selection.
7. The report appears using the filters you specified.
8. Study the Range & Exceptions graphs to guide your decision about what constitutes reasonable
threshold settings. See online help for this report for information about how to read this report.
Examples of Threshold Monitoring (HP Network Node Manager iSPI Performance
for Metrics Software)
You can configure interface threshold monitoring if the HP Network Node Manager iSPI Performance for
Metrics Software is installed. See "Purchase an HP Network Node Manager i Smart Plug-in" (on page 950)
for more information.
Several examples are presented These examples are not intended to be recommendations. Consider all
aspects of your network environment and set performance thresholds that are meaningful in your
environment:
l
Thresholds to Monitor Utilization on WAN Connections
l
Thresholds to Monitor Utilization on Important Interfaces
l
Thresholds to Monitor Important Interfaces for Discards
l
Thresholds to Monitor Important Interfaces for Errors
Example 1: Monitor Utilization on WAN Connections
You want to monitor the connections between two sites to verify that your service provider is meeting their
guaranteed throughput volume. You pay a fixed cost for a specific bandwidth over this WAN interface.
l
Monitor for under-utilization which wastes money (less than 10%).
Tip: If you don't care about under-utilization, set Low Value and Rearm to 0% as shown in Example 2.
l
Monitor for over-utilization, which may result in performance bottlenecks or service provider surcharges
(greater than 80%).
Page 230 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Note: Sometimes an Interface's MIB II ifspeed value is not reported accurately. This may result in threshold
calculations outside the 0.00 - 100.00 range. If this happens, the Interface threshold State set to "Unavailable." To correct the problem:
1. Access the Inventory workspace
2. Open Interface view.
3. Open the form for the Interface that is reporting a threshold state of "Unavailable."
4. Navigate to the General tab.
5. Enter a valid entry in Input Speed or Output Speed (this overrides the value returned by the device's
SNMP agent so that NNMi can accurately calculate utilization thresholds).
Example 2: Monitor Utilization on Important Interfaces
You want to monitor an important Ethernet interface and be notified if it is getting overloaded.
An Ethernet interface configured for full-duplex operation has an acceptable operating range of 0-60%.
When average utilization is greater than 60%, NNM generates a High Threshold incident.
Example 3: Monitor Important Interfaces for Discards
You want to know anytime an interface is dropping data. The acceptable limit for interface discards is 10%.
The threshold state is High when the discard rate exceeds 10% and returns to Nominal when the discard
rate drops below 5%.
Page 231 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Example 4: Monitor Important Interfaces for Errors
You want to know if packet errors occur. The acceptable limit for packet errors is 2%.The threshold state is
High Level (HL) when the error rate exceeds 2% and returns to normal when the error rate drops below
1%.
Configure Node Monitoring
Before you start, you must establish one or more Node Group definitions that identify the nodes to which
these monitoring settings will apply. See also, "Node Groups Provided by NNMi" (on page 207).
To establish monitoring behavior for a predefined Node Group:
1. Navigate to the Node Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
Page 232 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
b. Select Monitoring Configuration.
c. Locate the Node Settings tab.
d. Do one of the following:
o To create a Node Settings definition, click the
o To edit a Node Settings definition, click the
New icon.
Open icon in the row representing the
Node Settings definition you want to edit.
2. Establish the appropriate settings to identify this Node Setting definition (see Basics table).
3. Optional. Configure the Fault Monitoring behavior for this Node Setting definition (see Fault
Monitoring table).
4. (HP Network Node Manager iSPI Performance for Metrics Software) If the HP Network Node
Manager iSPI Performance for Metrics Software is installed:
n
Configure the Performance Monitoring behavior for this Node Setting definition (see Performance
Monitoring table).
n
Optional. Navigate to the Threshold Settings tab to configure the HP Network Node Manager iSPI
Performance for Metrics Software. See "Configure Threshold Monitoring for Nodes (HP Network
Node Manager iSPI Performance for Metrics Software)" (on page 238) for more information.
5. By default, NNMi monitors only interfaces that are connected to other interfaces. When SNMP polling
is enabled, NNMi automatically detects most connections. See "Add or Delete a Layer 2 Connection"
(on page 174) for information about manual overrides.
Optional. If you want to expand monitoring behavior for this group to include unconnected Interfaces,
indicate your choices in the Extend the Scope of Polling Beyond Connected Interfaces group box.
6. Click
Save and Close. NNMi applies your changes. The next regularly scheduled monitoring
cycle uses the new settings.
Caution: When you establish monitoring configuration settings, NNMi must recalculate membership
in all Node Groups and Interface Groups. This can take some time and slow down your
system. Consider making this change during a slow time in your network environment.
To verify that State Poller is working as expected, see the report on the State Poller tab in Help →
System Information.
Optional. Customize the interface monitoring behavior. See "Configure Interface Monitoring" (on page 221)
.
Basics
Attribute
Description
Ordering
Enter a unique string (any length), characters 0 through 9. Consider using increments of 100
for the flexibility to insert additional items between existing items over time.
NNMi decides which monitoring configurations apply to a node or interface based on the
ordering number assigned to the configuration definitions. NNMi monitors the device
according to the first match (checked from lowest number to highest number within each
category). Categories are read in sequence. Click here for a description of the sequence.
1. Interface Settings: NNMi monitors each of the Node's Interfaces and IP Addresses
based on the first matching Interface Settings definition. The first match is the Interface
Settings definition with the lowest Ordering number.
Page 233 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
2. Node Setting: NNMi monitors each Node and each previously unmatched Interface or
IP Address based on the first matching Node Settings definition. The first match is the
Node Settings definition with the lowest Ordering number.
Note: Child node groups are included in the Ordering hierarchy. This means that if the
parent node group has a lower Ordering number (for example, parent=10,
child=20), then the monitoring configuration specified for the parent node group
also applies to the nodes in the child node group. To override a parent node
group monitoring configuration, set the Ordering number for the child node group
to a number that is lower than the parent (for example, parent=20, child=10).
3. Default Settings: If no match is found for a Node, Interface, or IP Address in 1 or 2,
NNMi applies the default Monitoring Configuration settings.
No duplicate Ordering numbers are allowed. Each Node Setting ordering number must be
unique.
Node
Group
Choose one predefined Node Group from the list. See "Create Node Groups" (on page 179)
for more information.
(NNMi Advanced with IPv6 enabled) See also "Node Groups of IPv4 or IPv6 Addresses " (on
page 188).
Fault Monitoring (choose one or none)
Attribute
Description
Enable ICMP
Management Address
Polling
If enabled, State Poller only issues ICMP (ping) requests to IP addresses
classified as management addresses in the NNMi database. Note: In the
Global Control section of the Monitoring Configuration form, the Enable State
Polling attribute must be enabled, too.
If
Enable ICMP Fault
Polling
Note: This monitoring
option is useful for
devices that do not
support SNMP. By
default, this feature is
enabled for the "NonSNMP Devices" Node
Group.
Page 234 of 1087
disabled, State Poller does one of the following:
l
If neither this attribute nor Enable ICMP Fault Polling is selected, State
Poller does not use ICMP to monitor nodes covered by this configuration
setting.
l
If Enable ICMP Fault Polling is selected, State Poller uses ICMP to monitor
ALL IP addresses covered by this configuration setting.
If enabled, State Poller issues ICMP (ping) requests to verify the availability
of discovered IP address. Note: In the Global Control section of this form, the
Enable State Polling attribute must be enabled, too.
If
disabled, State Poller does the following:
l
If neither this attribute nor Management IP Address Polling is selected,
State Poller does not use ICMP to monitor nodes covered by this
configuration setting.
l
IP addresses (both previously discovered and newly discovered) have a
State attribute value of "Not Polled" and a Status attribute value of "No
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Status" with the color of the IP address map-symbol set to beige. See Layer
3 Neighbor View.
l
If both ICMP and SNMP are disabled for a Node, the Node has a Status
attribute value of "No Status" and the color of the Node map-symbol
background shape is set to beige.
Tip: To turn off ICMP polling within a subset of your network environment, use
the Communication Configuration workspace Region definitions. You can
define your own Regions that identify any unreachable addresses in your
management domain (for example, the private IP addresses 1).
Enable SNMP Interface
Fault Polling
If enabled, State Poller monitors all interfaces by issuing SNMP read-only
queries to devices assigned to this level of the monitoring hierarchy.
By default, any connected interface is monitored for MIB II ifAdminStatus and
ifOperStatus. (ifAdminStatus is set by the device administrator. ifOperStatus
indicates the operational status of interface health.) If you have unconnected
interfaces that you want to monitor, expand NNMi monitoring behavior with the
Poll Unconnected Interfaces and the Poll Interfaces Hosting IP Addresses
attributes.
Note: The following attributes must also be enabled:
l
In the Global Control section of this form, the Enable State Polling attribute
must be enabled, too. See Layer 2 Neighbor View. (See "Set Global
Monitoring" (on page 215) for more information.)
l
In the Communication Configuration view, enable State Poller queries with
the applicable Enable SNMP Communication attributes (see "Configuring
Communication Protocol" (on page 66) for more information).
If
disabled, for devices assigned to this level of the monitoring hierarchy:
l
Causal Engine calculates Status based only on IP address State.
l
The Interface objects previously discovered change to a State attribute
value of "Not Polled" and a Status attribute value of "No Status" (plus any
related map-symbol changes to a beige color).
1These are IPv4 addresses that can be reused in home and office local area networks (LANs). Following
the standards set by RFC 1918 and RFC 4193 (10.*.*.*, 169.254.*.*, 172.16-31.*.*, and 192.168.*.*)
Page 235 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Enable Card Fault
Polling
Use this attribute to poll fault metrics for cards. Card fault metrics include
Administrative State, Operational State, and Standby State.
Note: Card Fault Polling is enabled by default.
If enabled, NNMi gathers fault data related to the card fault metrics in
devices assigned to this level of the monitoring hierarchy.
If disabled, NNMi does not extend data collection behavior to include card
fault data about devices assigned to this level of the monitoring hierarchy.
Note: NNMi uses the same polling interval set for the Fault Polling Interval.
Enable Node
Component Fault
Polling
Note: By default, this
feature is enabled for
the "Routers" and
"Networking
Infrastructure Devices"
Node Groups.
Use this attribute to poll Node Component fault metrics. Node Component fault
metrics include the following: Fan, Power Supply, Temperature, and Voltage.
Note: Node Component Fault Polling is disabled by default.
If enabled, NNMi gathers fault data related to the Node Component fault
metrics in devices assigned to this level of the monitoring hierarchy.
If disabled, NNMi does not extend data collection behavior to include Node
Component fault data about devices assigned to this level of the monitoring
hierarchy.
Note: NNMi uses the same polling interval set for the Fault Polling Interval.
Fault Polling Interval
The time that State Poller waits between issuing queries to gather information
for any of the following that are enabled: ICMP Polling, SNMP Polling, Poll
Unconnected Interfaces, and Poll Interfaces Hosting IP addresses.
Note: NNMi monitors SNMP agents (Management Addresses) according to
this Fault Polling Interval, even if ICMP Polling, SNMP Polling, Poll
Unconnected Interfaces, and Poll Interfaces Hosting IP addresses are
all disabled. To prevent an SNMP Agent's address from being
monitored, one of the following must be true: State Polling is disabled,
current Communication Configuration settings turn off SNMP for the
SNMP agent's address, or the parent Node is set to Not Managed or Out
of Service.
Performance Monitoring (HP Network Node Manager iSPI Performance for Metrics Software)
Attribute
Description
Enable SNMP
Interface
Performance Polling
(HP Network Node Manager iSPI Performance for Metrics Software) Use this
attribute to extend the range of polling data that NNMi collects. HP Network
Node Manager iSPI Performance for Metrics Software uses the additional data
in a series of performance reports. See "Purchase an HP Network Node
Manager i Smart Plug-in" (on page 950) for more information. When enabled,
network traffic increases on your network because NNMi gathers performance
data about each member of this group on a regular schedule.
If enabled, NNMi gathers performance data from Interfaces, CPU, memory,
and buffers in devices assigned to this level of the monitoring hierarchy.
If disabled, NNMi does not extend data collection behavior to include
performance data about devices assigned to this level of the monitoring
hierarchy.
Page 236 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
Note: The Enable State Polling field must be enabled, too. By default the
performance of connected interfaces and addresses is monitored. If you
have unconnected interfaces that you want to monitor, expand NNMi
monitoring behavior by enabling Poll Unconnected Interfaces.
Enable Node
Component
Performance Polling
Note: By default, this
feature is enabled for
the "Routers" Node
Group if HP Network
Node Manager iSPI
Performance for
Metrics Software is
installed.
(HP Network Node Manager iSPI Performance for Metrics Software) Use this
attribute to poll Node Component performance. An NNMi administrator can set
the threshold for node components related to the following performance metrics:
CPU utilization, memory utilization, buffer utilization, buffer miss rate, and buffer
failure rate.
Note: Node Component Performance Polling is disabled by default.
If enabled, NNMi gathers performance data related to the Node Component
performance metrics in devices assigned to this level of the monitoring
hierarchy.
If disabled, NNMi does not extend data collection behavior to include Node
Component performance data about devices assigned to this level of the
monitoring hierarchy.
Note: NNMi uses the same polling interval set for the Performance Polling
Interval.
Performance Polling
Interval
(HP Network Node Manager iSPI Performance for Metrics Software) Use this
field to set the time period that NNMi waits between issuing network traffic to
gather performance data for the HP Network Node Manager iSPI Performance
for Metrics Software.
Page 237 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Extend the Scope of Polling Beyond Connected Interfaces
Attribute
Description
Poll Unconnected
Interfaces
If enabled, NNMi monitors all interfaces within discovered devices (both
connected and unconnected). All interfaces are monitored for MIB II ifAdminStatus
and ifOperStatus. (ifAdminStatus is set by the device administrator. ifOperStatus
indicates the operational status of interface health.) Note: The Enable State
Polling field must be enabled, and SNMP polling of some type must be enabled
(for example, Enable SNMP Fault Monitoring and Enable SNMP Performance
Polling).
If
disabled, State Poller polls according to other configuration settings.
Tip: Your discovery configuration choices may need to be adjusted to get the
results you want. For example, to meet the “connected” criteria for interfaces in
switches that do not have an IP address you must add the device to which the
interface is connected as a discovery seed. See"Discovery Seeds (as a starting
point)" (on page 118).
Poll Interfaces
Hosting IP
Addresses
Note: This
monitoring option is
useful for Router
interfaces. By
default, this feature
is enabled for the
"Routers" Node
Group.
If enabled, any unconnected interface that has one or more addresses
associated with it is monitored for MIB II ifAdminStatus and ifOperStatus.
(ifAdminStatus is set by the device administrator. ifOperStatus indicates the
operational status of interface health.) Note: The Enable State Polling field must
be enabled, and SNMP polling of some type must be enabled (for example,
Enable SNMP Fault Monitoring and Enable SNMP Performance Polling).
By monitoring the Interface (in addition to the IP address), NNMi can make more
informed decisions about the health of each IP address associated with an
unconnected interface.
If
disabled, State Poller polls according to other configuration settings.
Tip: The Communication Configuration workspace provides a method of
overriding this setting for specific Regions. You can define your own Region to
easily turn off polling to any unreachable addresses in your management
domain (for example, the private IP addresses 1).
Configure Threshold Monitoring for Nodes (HP Network Node Manager iSPI Performance for Metrics Software)
The Threshold Settings form is used only to configure threshold monitoring when HP Network Node
Manager iSPI Performance for Metrics Software is installed. See "Purchase an HP Network Node Manager
i Smart Plug-in" (on page 950) for more information. If you set thresholds, NNMi generates an Incident
when any threshold is violated. Examples of the types of threshold you can set for a node include the
following: (See Monitored Attributes in the table below for a complete list.)
l
CPU 5 second utilization
l
CPU 1 minute utilization
l
CPU 5 minute utilization
l
Memory utilization
1These are IPv4 addresses that can be reused in home and office local area networks (LANs). Following
the standards set by RFC 1918 and RFC 4193 (10.*.*.*, 169.254.*.*, 172.16-31.*.*, and 192.168.*.*)
Page 238 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
l
Buffer utilization
l
Buffer miss rate
l
Buffer failure rate
The HP Network Node Manager iSPI Performance for Metrics Software provides exceptions reports to
track frequency. HP Network Node Manager iSPI Performance for Metrics Softwaremonitors your network
traffic. Network traffic increases while NNMi gathers performance data.
To establish threshold monitoring behavior for the HP Network Node Manager iSPI Performance for
Metrics Software:
1. After enabling Performance Monitoring for a Node Group and before setting thresholds, analyze
performance data over time to determine wise threshold settings for each group. See "Determine
Reasonable Threshold Settings (HP Network Node Manager iSPI Performance for Metrics Software)"
(on page 229).
2. Navigate to the Thresholds Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Monitoring Configuration.
c. Navigate to the Node Settings tab.
d. Do one of the following:
o To create a Node Settings definition, click the
o To edit a Node Settings definition, click the
New icon.
Open icon in the row representing the
Node Settings definition you want to edit.
3. Prerequisite. Verify that Performance Monitoring is enabled for this Node Settings definition.
4. In the Node Settings form, navigate to the Threshold Settings tab.
5. Do one of the following:
n
To create a threshold definition, click the
n
To edit a threshold definition, click the
definition you want to edit.
n
To delete a threshold definition, select a row and click the
New icon.
Open icon in the row representing the threshold
Delete icon.
6. Select the attribute you want to monitor and establish the threshold values for that attribute (see Basic
Threshold Settings table). For examples of setting meaningful thresholds, see "Examples of
Threshold Monitoring (HP Network Node Manager iSPI Performance for Metrics Software)" (on page
230).
7. Click
Save and Close to return to the Node Settings form.
8. Click
Save and Close to return to the Monitoring Configuration form.
9. Click
Save and Close. NNMi applies your changes during the next regularly scheduled
monitoring cycle.
Note: Threshold Incidents are disabled by default within NNMi to prevent Incident storms. If you are
ready to generate Threshold Incidents, see "Generate Performance Threshold Incidents (HP
Network Node Manager iSPI Performance for Metrics Software)" (on page 422). And to learn
Page 239 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
about your incident configuration choices, see "Custom Incident Attributes Provided by NNMi
(for Administrators)" (on page 310) for a description of the special custom incident attributes
available in Threshold Incidents.
To verify that State Poller is working as expected, see the report on the State Poller tab in Help →
System Information.
Basic Threshold Settings
Attribute
Description
Monitored
Attribute
NNMi gathers data to calculate thresholds for the following values. Click any item in this list
for more details about that value.
Note: NNMi also displays the Monitored Attributes that apply to interfaces. See "Configure
Threshold Monitoring for Interfaces (HP Network Node Manager iSPI Performance for
Metrics Software)" (on page 226) for more information about these attributes
High
Value
l
CPU 5Sec Utilization
Percentage of CPU usage in relation to the total amount of CPU available. This
percentage is measure at 5-second intervals.
l
CPU 1Min Utilization
Percentage of CPU usage in relation to the total amount of CPU available. This
percentage is measured at 1-minute intervals.
l
CPU 5Min Utilization
Percentage of CPU usage in relation to the total amount of CPU available. This
percentage is measured at 5-minute intervals.
l
Memory Utilization
Percentage of memory usage in relation to the total amount of memory available.
l
Buffer Utilization
Percentage of buffer usage in relation to the total amount of buffer space available.
l
Buffer Miss Rate
Counter indicating that the number of available buffers in the pool has dropped below
the minimum level.
l
Buffer Failure Rate
Percentage value based on the number of buffer failures caused by insufficient memory
when trying to create additional buffers.
Designate the percentage above which would indicate a value in the High range. Valid
entries are 0.00 through 100.00
Note: If you use 100.00 the threshold is disabled because it cannot be crossed.
High
Value
Rearm
Designate the percentage that when reached would indicate the end of a high threshold
situation. Valid entries are 0.00 through 100.00
High
Trigger
Count
Designate the number of consecutive polling cycles in which the value must remain in the
High range before the threshold state changes to High.
Low
Value
The Low Value must be less than or equal to the High Value.
Note: The High Value Rearm must be less than or equal to the High Value and greater than
the Low Value Rearm.
Designate the percentage below which would indicate a value in the low range. Valid
Page 240 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Attribute
Description
entries are 0.00 through 100.00
Note: If you use 0.00 the threshold is disabled because it cannot be crossed.
Low
Value
Rearm
Designate the percentage that when reached would indicate the end of a low threshold
situation. Valid entries are 0.00 through 100.00.
Low
Trigger
Count
Designate the number of consecutive polling cycles in which the value must remain in the
Low range before the threshold state changes to Low.
Note: The Low Value Rearm must be greater than or equal to the Low Value and less than
the High Rearm Value.
Configure Node Group Status
NNMi enables an NNMi administrator to configure the Node Group status calculations using either of the
following methods:
l
Assign the Node Group the most severe status of any Node Group member. This is the default method
for obtaining Node Group Status.
l
Configure the percentage thresholds for one or more Node Group target statuses. For example, when
defining percentage values for a target status of Critical, you might change the default so that 30
percent of the nodes in the group must have a status other than Normal, for the Node Group Status to
be Critical.
To configure Node Group status calculations, do the following:
1. Navigate to the Status Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Status Configuration.
2. Make one of the following configuration choices:
To assign the Node Group the most severe Status of any Node Group member, in the Status
Configuration form, under Global Control, make sure Propagate Most Severe Status is
checked:
n
Propagate Most Severe Status
To configure percentage values for a Node Group Target Status, do the following:
n
n
In the Status Configuration form, under Global Control, make sure the Propagate Most
Severe Status is cleared:
Propagate Most Severe Status
n
3. Click
Configure the percentage values for a Node Group Target Status
Save and Close.
NNMi applies your changes after the configuration is saved.
Configure Percentage Values for the Target Status
NNMi enables you to configure how the status of a Node Group is calculated.
Page 241 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Note: The percentage is calculated using only those nodes in the Node Group that have a Management
Mode value of Managed. For example, if a Node Group includes 10 nodes and 3 of the nodes are
Not Managed, 5 of the nodes have a Status of Normal, and 2 have a status of Critical, the
percentage of Critical nodes is 2/7 * 100.
To configure the percentage values for a Node Group Target Status:
1. Navigate to the Status Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Status Configuration.
2. Locate the Node Group Status Settings tab.
3. Do one of the following:
n
To create a Node Group Status Settings definition, click the
n
To edit a Node Group Status Settings definition, click the
Open icon in the row representing
the Node Group Status Settings definition you want to edit.
n
To delete a Node Group Settings definition, select a row and click the
New icon.
Delete button
4. Establish the appropriate settings to identify this Node Group Status Settings definition. (See the
"Node Group Status Settings Form" (on page 242) form)
Note: You can only define one configuration for each Target Status.
Node Group Status Settings Form
The Node Group Status Settings form is used to configure the percentage thresholds for a Node Group
Target Status. The percentage thresholds you specify define what percentage of nodes within the group
must have a particular Status. When the percentage thresholds are reached, the Node Group is assigned
the associated Target Status. For example, when defining percentage thresholds for a target status of
Critical, you might change the default so that 10 percent of the nodes in the group must have a status of
Critical for the Node Group Status to be Critical.
Note: Use a percentage threshold between 0 (zero) and 1 (for example, .01) to indicate the Target Status
to be reached when one node in the Node Group reaches a specified Status. For example, if you
want the Node Group Status to be set to Critical when the Status of one node in the Group becomes
Critical, enter a percentage less than one for the Critical % value.
To define percentage thresholds for a Target Status:
1. Navigate to the Node Group Status Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Status Configuration.
c. Navigate to the Node Group Status Settings tab.
d. Do one of the following:
o To create a Node Group Status Settings definition, click the
o To edit a Node Group Settings definition, click the
New icon.
Open icon in the row representing
the Node Group Settings definition you want to edit.
o To delete a Node Group Settings definition, select a row and click the
2. Set the Target Status and percentages you want (see Basic Attributes table).
Page 242 of 1087
Delete icon.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
3. Click
Save and Close to return to the Status Configuration form.
4. Click
Save and Close. NNMi applies your changes after the configuration is saved.
Basics Attributes
Attribute
Description
Target
Status
The Status you are configuring. This Status is assigned to the Node Group whenever the
specified percentage thresholds are reached.
Note the following:
l
Whether all or one of the percentage thresholds must be reached for a Target Status
configuration depends on the Boolean operator you select. The default Boolean
operator is OR. (Also see Combine with AND below.)
l
If you do not specify any percentages for a Target Status, it does not appear as a Status
for a Node Group.
Critical %
Specifies the required percentage of nodes in the group that must have a Status value set to
Critical before NNMi assigns the Target Status.
Major %
Specifies the required percentage of nodes in the group that must have a Status value set to
Major before NNMi assigns the Target Status.
Minor %
Specifies the required percentage of nodes in the group that must have a Status value set to
Minor before NNMi assigns the Target Status.
Warning
%
Specifies the required percentage of nodes in the group that must have a Status value set to
Warning before NNMi assigns the Target Status.
NonNormal
%
Specifies the required percentage of nodes in the group that must have a Status value set to
any of the following before NNMi assigns the Target Status:
l
Critical
l
Major
l
Minor
l
Warning
Unknown
%
Specifies the required percentage of nodes in the group that must have a Status value set to
Unknown before NNMi assigns the Target Status.
Combine
with AND
Specifies that you want NNMi to combine the percentage thresholds you enter using the
AND Boolean operator.
When using this option, note the following:
l
All percentage thresholds you enter must be reached for the Node Group to be assigned
the Target Status.
l
The percentage thresholds you enter must not exceed 100 percent.
Page 243 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
Monitor Router Redundancy Groups (NNMi Advanced)
NNMi monitors state and priority information for any discovered HSRP and VRRP objects in the network.
These objects include Router Redundancy Members and Tracked Objects. See Router Redundancy
Group View for more information about Router Redundancy Groups and the HSRP or VRRP objects
associated with them.
The polling interval used is the Fault Polling Interval that is set for the node associated with the Router
Redundancy Member or Tracked Object.
If you do not want these objects polled:
l
Set the Management Mode for each node to Not Managed or Out of Service. See "Stop or Start
Managing a Node, Interface, Card, Address, or Node Component" (on page 248) for more information
about Management Mode.
l
Disable all Router Redundancy Group monitoring. See "Set Global Monitoring" (on page 215).
NNMi Advanced also uses these HSRP and VRRP objects when calculating a Path View between two
nodes that have IPv4 addresses. See Path View with NNMi Advanced for more information.
Current Health of the State Poller Service
At any time, you can check the current health statistics about the State Poller Service.
To see a report of the health of the State Poller Service, click Help → System Information and navigate to
the State Poller tab. For more information see Displaying NNMi System Information.
The State Poller Service contributes towards discovery and ongoing monitoring. See "About Each NNMi
Service" (on page 46).
Verify Monitoring Configuration Settings
After you configure the monitoring settings, you can check the configuration for a particular object to verify
that everything is working correctly. Examples of objects on which you can verify monitoring configuration
settings include Nodes, Interfaces, IP addresses, Router Redundancy Groups, Tracked Objects, and Node
Components. Use the Actions → Monitoring Settings menu item to display a report.
(NNMi Advanced) If the Global Network Management feature is enabled and you are signed into a Global
Manager:
l
Node managed by the Global Manager = Actions → Monitoring Settings displays a report, provided by
the Global Manager (NNMi management server).
l
Node managed by a Regional Manager = Actions → Monitoring Settings accesses that Regional
Manager (NNMi management server) and requests the report.
Note: You must sign into that Regional Manager unless your network environment enables Single
Sign-On (SSO) to that Regional Manager through the Global Manager.
To verify the monitoring configuration for a Node, Interface, IP address, or Card:
1. Navigate to the view for that object (for example, Inventory workspace, Nodes) view.
2. Select the object of interest by selecting the
3. Select Actions → Monitoring Settings.
Page 244 of 1087
check box that precedes the object information.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
NNMi displays the monitoring configuration settings for the selected object.
Note: This menu item also is available on any object's form.
To verify the monitoring configuration for a Router Redundancy Member:
1. Navigate to a Router Redundancy Group view (for example, Inventory workspace, Router
Redundancy Groups view).
2. Click the
Open icon in the row representing the Router Redundancy Group configuration you
want to see.
3. From the Router Redundancy Members tab, click the
Open icon in the row representing the
Router Redundancy Member configuration you want to edit.
NNMi displays the monitoring configuration settings for the selected object.
4. Select Actions → Monitoring Settings.
To verify the monitoring configuration for a Tracked Object:
1. Navigate to a Router Redundancy view (for example, Inventory workspace, Router Redundancy
Groups view).
2. Click the
Open icon in the row representing the Router Redundancy Group configuration you
want to see.
3. From the Router Redundancy Members tab, click the
Open icon in the row representing the
Router Redundancy Group Member configuration you want to see.
4. From the Tracked Objects tab, click the
configuration you want to see.
Open icon in the row representing the Tracked Object
5. Select Actions → Monitoring Settings.
NNMi displays the monitoring configuration settings for the selected object.
To verify the monitoring configuration for a Node Component:
1. Navigate to the view for that object (for example, Inventory workspace, Nodes view).
2. Click the
Open icon in the row representing the Node Component Configuration you want to see.
3. Select the Node Component tab.
4. Select the Node Component of interest by selecting the
information.
check box that precedes the object
5. Select Actions → Monitoring Settings.
NNMi displays the monitoring configuration settings for the selected object.
Check status and connectivity of important interfaces.
1. Open a Layer 2 Neighbor View map of each important interface's parent device. See Viewing Maps
(Network Connectivity).
Page 245 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
2. Each connected interface has a little square symbol around the edge of the parent device's map
symbol. For example:
3. Hover your mouse over the square to verify the identify of your important interface on the map.
4. Verify that the status color of each important interface is not Unknown or
About Status Colors). For example:
Unmanaged1 (see
5. By default, NNMi only monitors the health of connected interfaces. A line appears on the map
between interfaces when they are connected. For example:
6. If you need to add a connection, see "Add or Delete a Layer 2 Connection" (on page 174).
Check status and connectivity of important addresses.
1. Open a Layer 3 Neighbor View map of each important parent device. See Viewing Maps (Network
Connectivity).
2. Each address that is connected to another address in the same subnet has a little hexagon symbol
around the edge of the parent device's map symbol. For example:
3. Hover your mouse over the hexagon to verify the identify of your important address on the map.
4. NNMi monitors the health of addresses only if you enable ICMP Address Monitoring. A line appears
on the map between addresses when they are connected. The line represents the subnet. For
example:
1Indicates the Management Mode is "Not Managed" or "Out of Service".
Page 246 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Monitoring Network Health
5. If ICMP Address Monitoring is enabled, verify that the status color of each important address is not
Unknown or Unmanaged1 (see About Status Colors). For example:
6. If you need to add a connection, see "Add or Delete a Layer 2 Connection" (on page 174).
See "Configure Monitoring Behavior" (on page 214) for information about establishing monitoring
behavior.
Monitor Status Distribution for Network Objects
NNMi enables you to view the overall health of your network by providing Stacked Area Graphs that
display the distribution of Node, Interface, and IP Address Status information over time.
Tip: If you do not want to display unpolled objects (No Status), use the File → Select Area menu option
and clear the No Status check box.
To view Status Distribution Graphs:
1. Select Tools → Status Distribution Graphs.
2. Select the object type for which you want to display Status distribution. For example, Node Status.
NNMi displays a Stacked Area Graph of the distribution of the object's Status over time.
See Help → Using Stacked Area Graphs from the Graph menu bar for more information about using
Stacked Area Graphs.
See "Configure Monitoring Behavior" (on page 214) for information about establishing monitoring
behavior.
1Indicates the Management Mode is "Not Managed" or "Out of Service".
Page 247 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
Stop or Start Managing a Node, Interface, Card, Address, or Node
Component
NNMi administrators can specify that a node, interface, card, address, or node component should no
longer be discovered or monitored (Management Mode = Unmanaged) or is out of service (Management
Mode = Out of Service). For additional information see the form for each object:
Reasons you might want to change the management mode include:
l
The node is temporarily out of service.
l
You determine that NNMi should never monitor a particular node, interface, card, IP address, or node
component.
NNMi provides two management modes for each object (as described in the table). For more information,
see the following topics:
l
"View the Management Mode for Objects in Your Network" (on page 249)
l
"How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address" (on
page 252)
l
"How the NNMi Administrators Change a Management Mode" (on page 254)
l
"Understand the Effects of Setting the Management Mode to Not Managed or Out of Service " (on page
255)
Management Modes
Name
Description
Node
For Node objects, this value is set by the NNMi administrator. The node-level
Management Management Mode affects the Management Mode of objects associated with the node.
Mode
For interface, card, node component, or address, the Management Mode cannot be set
or
by the NNMI administrator. NNMi calculates value. The Management Mode for an
interface, card, or node component is computed based on the Management Mode for the
Management node. The Management Mode value for an address is calculated based on the
Mode
Management Mode for the associated interface (if any) or based on the Management
Mode for the node.
Possible values include:
Managed - Used to indicate a node, interface, or address should be discovered and
monitored by NNMi.
Not Managed - Used to indicate that NNMi should not discover or monitor the object. For
example, the object might not be accessible because it is in a private network.
Out of Service - Used to indicate a node, interface, or address is unavailable because it
is out of service. NNMi does not discover or monitor these objects.
Tip: Some objects have child objects (for example, Nodes contain interfaces, and
interfaces can contain IP addresses). To change the Management Mode back to
Managed or Inherited for the selected object and all associated child objects, use the
Actions → Management Mode → Managed (Reset All).
Page 248 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
Name
Description
Direct
For interfaces, cards, node components, and addresses, this value is set by the NNMi
Management administrator.
Mode
NNMi uses this value to compute the Management Mode values in the previous row in
this table. Possible values include:
Inherited - For interfaces, cards, and node components, this value is used to indicate that
the object should inherit the Management Mode from the node in which it resides. For
addresses, this value is used to indicate that the Management Mode should be inherited
from the associated interface, if one exists. Otherwise the Management Mode is inherited
from the node in which it resides.
Not Managed - Used to indicate that NNMi should not discover or monitor the object. For
example, the object might not be accessible because it is in a private network.
Out of Service - Used to indicate the object is unavailable because it is out of service.
Reasons might include the interface, card, or node component is being repaired or there
is a known problem with the address. NNMi does not discover or monitor these objects.
View the Management Mode for Objects in Your Network
NNMi provides the Management Mode workspace so that you can quickly view lists of all nodes,
interfaces, cards, addresses, or node components that NNMi is not currently discovering or monitoring. For
information about these views:
The following tables describes each possible Management Mode and Direct Management Mode value.
The available Management Mode values depend on the object type (node, interface, card, address, or
node component). Management Modes are either set automatically by NNMi or set by the NNMi
administrators.
Management Mode Values
Object
Value
Description
Node
Managed
Used to indicate that the node should be managed by NNMi. This means it will be
discovered and monitored.
Node
Not
Managed
Used to indicate you do not plan to manage the node. For example, the node might
not be accessible because it is in a private network. NNMi does not discover or
monitor these objects.
Node
Out of
Service
Used to indicate the node is unavailable because it is out of service. Reasons might
include that the device is being repaired or there is a known problem with the
device. NNMi does not discover or monitor these objects.
Direct Management Mode Values
Object
Value
Interface,
Not
Card,
Managed
Address, or
Node
Component
Page 249 of 1087
Description
Used to indicate you do not plan to manage the interface, card, address, or
node component. After the Direct Management Mode is set to Not Managed,
NNMi no longer discovers or monitors the object.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
Object
Value
Interface,
Out of
Card,
Service
Address, or
Node
Component
Description
Used to indicate that the object is out of service. NNMi does not discover or
monitor these objects.
An interface, card, or node component will not be managed again until the
Direct Management Mode is set to Inherited and its associated node is set to
Managed.
An address will not be managed again until the Management Mode of any
associated interface is set to Inherited and the node's Management Mode is
set to Managed.
Interface,
Inherited
Card,
Address, or
Node
Component
Used to indicate that the object should assume the Management Mode of the
node in which it is hosted.
Address
The address assumes the Management Mode of the interface, if any, with
which the address is associated.
Inherited
Note: To manage the interface, card or node component, the Management
Mode of the node in which the interface is hosted must be Managed.
If the address is not associated with an interface, it assumes the Management
Mode of the node in which it is hosted.
Note: To manage the address, the Management Mode of the address'
interface, if any, must be calculated to be Managed. The Management
Mode of the node in which the interface and address are hosted must
be set to Managed.
Unmanaged Nodes View
The Unmanaged Nodes view identifies all of the nodes with a management mode of either Not Managed
or Out of Service. These are the nodes that are no longer being discovered or monitored.
Use this view to select nodes and change the Management Mode to Managed. For information:
For each node, you can identify its overall status ( for example, Normal, Warning, Minor, Major, Critical
and Unknown), device category (for example, switch), name, system name, management address, system
location (the current value of the sysLocation MIB variable), device profile, whether the SNMP Agent is
enabled, the date and time the status was last modified, and any notes included for the node.
See "Using the Nodes View" for more information about uses for nodes views.
Related Topics
"How the NNMi Administrators Change a Management Mode" (on page 254)
"How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address" (on page
252)
"Understand the Effects of Setting the Management Mode to Not Managed or Out of Service " (on page
255)
"View the Management Mode for Objects in Your Network" (on page 249)
Page 250 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
Unmanaged Interfaces View
Tip: See Interface Form for more information about the attributes that appear in each column in this view.
The Unmanaged Interfaces view identifies all of the interfaces with a Management Mode of Not Managed
or Out of Service. These are the interfaces that are no longer being discovered or monitored.
Use this view to select interfaces and change the Management Mode to Managed. For information:
For each interface, you can identify the interface's overall status (for example, Normal, Warning, Minor,
Major, Critical, and Unknown), administrative state, operational state, the management mode of the
interface, the management mode of the associated node, the node on which the interface resides (Hosted
on Node), the interface name, type, speed, and alias, the date the interface status and state was last
changed, and any notes included for the interface.
See Interfaces View (Inventory) for more information about uses for the interfaces views.
Related Topics
"How the NNMi Administrators Change a Management Mode" (on page 254)
"How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address" (on page
252)
"Understand the Effects of Setting the Management Mode to Not Managed or Out of Service " (on page
255)
"View the Management Mode for Objects in Your Network" (on page 249)
Unmananaged Addresses View
Tip: See IP Address Form for more information about the attributes that appear in each column in this view.
The Unmanaged Addresses view identifies all of the addresses with a Management Mode of Not
Managed or Out of Service. These are the addresses that are no longer being discovered or monitored.
Use this view to select addresses and change the Management Mode to Managed. For information:
For each IP address, you can identify its status, state, management mode, the management mode of its
associated node, the IP address value, the name of the interface on which the address resides (In
Interface), the name of the node on which the address resides (Hosted on Node), subnet (In Subnet) and
prefix length (PL), the date and time in which the status was last modified, and any notes included for the
IP address.
See IP Addresses View (Inventory) for more information about uses for address views.
Related Topics
"How the NNMi Administrators Change a Management Mode" (on page 254)
"How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address" (on page
252)
"Understand the Effects of Setting the Management Mode to Not Managed or Out of Service " (on page
255)
"View the Management Mode for Objects in Your Network" (on page 249)
Unmanaged Cards View
Tip: See Card Form for more information about the attributes that appear in each column in this view.
Page 251 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
The Unmanaged Cards view identifies all of the cards with a Management Mode of Not Managedor Out of
Service. These are the cards that are no longer being discovered or monitored.
Use this view to select cards and change the Management Mode to Managed. For information:
For each card, you can identify its status, management mode, the management mode of the node on which
it resides, the administrative state, the operational state, the name of the node on which the card resides
(Hosted On Node), the date and time the status was last modified, its name, model, type, serial number,
firmware version, hardware version, software version, index, the name of the card on which the card
resides, if any, any Redundant Group to which the card belongs, the date and time the state was last
modified, the card Description, and any notes included for the card.
Related Topics
"How the NNMi Administrators Change a Management Mode" (on page 254)
"How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address" (on page
252)
"Understand the Effects of Setting the Management Mode to Not Managed or Out of Service " (on page
255)
"View the Management Mode for Objects in Your Network" (on page 249)
Unmanaged Node Components View
Tip: See Node Component Form for more information about the attributes that appear in each column in
this view.
The Unmanaged Node Components view identifies all of the Node Components with a Management
Mode of Not Managed or Out of Service. These are the Node Components that are no longer being
discovered or monitored.
Use this view to select Node Components and change the Management Mode to Managed. For
information:
For each Node Component, you can identify its Status, Management Mode, the Management Mode of the
node on which it resides, its Name, type, the name of the node on which it resides (Hosted On Node), and
the date and time the Status was last modified.
Related Topics
"How the NNMi Administrators Change a Management Mode" (on page 254)
"How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address" (on page
252)
"Understand the Effects of Setting the Management Mode to Not Managed or Out of Service " (on page
255)
"View the Management Mode for Objects in Your Network" (on page 249)
How NNMi Assigns the Management Mode to an Interface, Card, Node
Component, or Address
NNMi administrators can instruct NNMi to no longer manage an interface, card, node component, or
address by setting the Direct Management Mode value (see "How the NNMi Administrators Change a
Page 252 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
Management Mode" (on page 254)). NNMi then calculates the overall Management Mode based on the
current Management Mode of all the associated objects.
For example, if you are specifying the Direct Management Mode for an address, NNMi uses the following
values to determine the Management Mode value for the address:
l
Direct Management Mode you enter for the address
l
Management Mode of the associated interface, if any
l
Management Mode of the node that contains the address
The following table lists possible value combinations for each object's management mode.
To check the current Management Mode setting for objects see "View the Management Mode for Objects
in Your Network" (on page 249) and .
Interface, Card, and Node Component
Management Mode (Node)
Calaculated by NNMi
Direct Management Mode
(Interface, Card, or Node
Component)
Management Mode
(Interface, Card, or Node
Component)
Managed
Inherited
Managed
Not Managed
Inherited
Not Managed
Out of Service
Inherited
Out of Service
Managed
Not Managed
Not Managed
Not Managed
Not Managed
Not Managed
Out of Service
Not Managed
Not Managed
Managed
Out of Service
Out of Service
Not Managed
Out of Service
Out of Service
Out of Service
Out of Service
Out of Service
Address
Management Mode
(Node)
Direct Management Mode
(Interface)
Direct Management Mode
(Address)
Management Mode
(Address)
Managed
Inherited
Inherited
Managed
Not Managed
Inherited
Inherited
Not Managed
Out of Service
Inherited
Inherited
Out of Service
Managed
Not applicable*
Inherited
Managed
Not Managed
Not applicable*
Inherited
Not Managed
Out of Service
Not applicable*
Inherited
Out of Service
Managed
Not Managed
Inherited
Not Managed
Page 253 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
Management Mode
(Node)
Direct Management Mode
(Interface)
Direct Management Mode
(Address)
Management Mode
(Address)
Not Managed
Not Managed
Inherited
Not Managed
Out of Service
Not Managed
Inherited
Not Managed
Managed
Not Managed
Not Managed
Not Managed
Not Managed
Not Managed
Not Managed
Not Managed
Out of Service
Not Managed
Not Managed
Not Managed
Managed
Not applicable*
Not Managed
Not Managed
Not Managed
Not applicable*
Not Managed
Not Managed
Out of Service
Not applicable*
Not Managed
Not Managed
Managed
Out of Service
Inherited
Out of Service
Not Managed
Out of Service
Inherited
Out of Service
Out of Service
Out of Service
Inherited
Out of Service
Managed
Out of Service
Out of Service
Out of Service
Not Managed
Out of Service
Out of Service
Out of Service
Out of Service
Out of Service
Out of Service
Out of Service
Managed
Not applicable*
Out of Service
Out of Service
Not Managed
Not applicable*
Out of Service
Out of Service
Managed
Not applicable*
Out of Service
Out of Service
* Used to indicate there is no associated interface
How the NNMi Administrators Change a Management Mode
Caution: (NNMi Advanced - Global Network Management feature) If your NNMi console is a Global
Manager and the selected object is being managed by a Regional Manager (another NNMi
management server in your network environment), you cannot change the Management Mode
setting unless you log onto the Regional Manager (NNMi management server).
The NNMi administrator can change the Management Mode in one of the following ways:
l
Open the object's form, do one of the following, and then select File → Save and Close:
n
Use the Management Mode attribute's drop-down menu to choose an available Management
Mode for that object.
n
Use Actions → Management Mode and choose an available Management Mode for that object.
Note: If you are updating the Direct Management Mode for an interface, card, node component, or
address, NNMi also updates its Management Mode value after you reopen or refresh the form.
l
Open a view that contains the object and do the following:
Page 254 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
a. Select the object of interest:
o In a table view, check the
selection box that precedes the object information.
o In a map view, single-click the object.
b. Select Actions → Management Mode and choose an available Management Mode for that
object.
Tip: Some objects have child objects (for example, Nodes contain interfaces, and interfaces can
contain IP addresses). To change the Management Mode back to Managed or Inherited for
the selected object and all associated child objects, use the Actions → Management Mode
→ Managed (Reset All).
l
Use the nnmmanagementmode.ovpl command.
Make sure you review this information: "Understand the Effects of Setting the Management Mode to Not
Managed or Out of Service " (on page 255).
Related Topics:
"How NNMi Assigns the Management Mode to an Interface, Card, Node Component, or Address" (on page
252)
"View the Management Mode for Objects in Your Network" (on page 249)
Understand the Effects of Setting the Management Mode to Not Managed or Out of Service
NNMi administrators can instruct NNMi to no longer manage an interface, card, node component, or
address by selecting a Management Mode value on the object's form or by using Actions → Management
Mdoe. See "How the NNMi Administrators Change a Management Mode" (on page 254).
The results of setting the management mode to Not Managed or Out of Service for an object, depends on
whether you are setting the value for a node, interface, address, card, or node component:
l
Nodes: Management Mode
For nodes, setting the Management Mode to Not Managed or Out of Service has the following effects:
n
No incidents are generated for the node
n
The node's SNMP Agent is excluded from fault polling.
n
The node's interfaces or addresses are excluded from fault and performance polling.
n
NNMi quits gathering Node Component data.
n
NNMi deletes all Polled Instances associated with the Not Managed or Out of Service node.
n
The Active State for any Custom Poller Nodes associated with the Not Managed or Out of Service
node becomes Inactive.
n
The node is removed from any associated Router Redundancy Groups.
n
Traps related to the node, interface, card, node component, or address, (for example, coldStart or
warmStart) are not stored.
n
The node is excluded from discovery.
Page 255 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Stop or Start Managing a Node, Interface, Card, Address, or Node Component
l
n
Actions → Configuration Poll is no longer available for this node.
n
The status of a node is set to No Status.
n
Actions → Status Poll is no longer available for the node or incident related to that node.
Interfaces: Direct Management Mode
For interfaces, setting the Direct Management Mode to Not Managed or Out of Service has the
following effects:
l
n
No incidents are generated for the interface.
n
The interface and any related addresses are excluded from fault and performance polling.
n
The Administrative State and Operational State of the interface are set to Not Polled.
n
The Status of the interface is set to No Status.
n
Traps related to the interface (for example, LinkUp or LinkDown), will not be stored.
IPv4 / IPv6 Addresses: Direct Management Mode
For addresses, setting the Direct Management Mode to Not Managed or Out of Service has the
following effects:
l
n
No incidents are generated for the address.
n
The State of the address is set to Not Polled.
n
The address is excluded from fault and performance polling.
n
Traps related to the address are not stored.
Cards and Node Components: Direct Management Mode
Cards and Node Components, setting the Direct Management Mode to Not Managed or Out of
Service has the following effects:
n
No incidents are generated for the card or node component.
n
The State of the object is set to Not Polled.
n
The card or node component is excluded from fault and performance polling.
n
The Status remains set to the last known Status value.
n
Traps related to the card or node component are not stored.
NMi provides the Management Mode workspace so that you can quickly view lists of all nodes, interfaces,
cards, addresses, or node components that NNMi is not currently discovering or monitoring. For
information about these views:
To change the Management Mode back to Managed, use the Actions → Management Mode → Managed.
Tip: Some objects have child objects (for example, Nodes contain interfaces, and interfaces can contain IP
addresses). To change the Management Mode back to Managed or Inherited for the selected object
and all associated child objects, use the Actions → Management Mode → Managed (Reset All).
Page 256 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Configuring the NNMi User Interface
NNMi enables an NNMi administrator to configure the following global user interface features:
l
The console time out interval
l
The initial map view to display in the Topology Maps workspace
l
Whether NNMi displays unlicensed features that require a special license, such as NNMi Advanced
For information about the additional user interface configurations available, including creating user
accounts, configuring Node Group map settings, setting the default values for maps and Line Graphs, and
configuring menus and menu items:
To configure user interface features, do the following:
1. Navigate to the User Interface Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
2. Make your Global Control configuration choices (see the Global Control Attributes table).
3. Make your additional configuration choices. Click here for a list of choices .
4. Click
Save and Close to apply your changes.
5. To apply your Console Timeout or Initial View configuration changes, sign out of the NNMi console.
After restarting the console, your changes should take effect.
Global Control Attributes for User Interface Configuration
Attribute
Description
Console
Timeout
NNMi's default session inactivity timeout value is 18 hours. Use this attribute to change the
timeout interval in days, hours, and minutes.
Note: The minimum timeout value is 1 minute.
After this period, if no mouse movement occurs, the consoles locks and the user is
prompted to sign in again.
Tip: If your network operation center (NOC) has a large screen where a map of the most
important nodes is continuously displayed, use a launched view. See "Launch a
Troubleshooting Workspace View" (on page 970). A map session launched with a URL
never times out. The map launched automatically updates every 30 seconds. (If you are
using Mozilla Firefox, also see Configure Mozilla Firefox Timeout Interval.)
Initial View
Use this attribute to specify the initial view to be automatically displayed in the NNMi
console by default.
When selecting a view from the drop-down menu list, note the following:
l
Use the value None (blank) to specify that you do not want a default view automatically
displayed by default.
l
If the Node Group you select has been removed, NNMi uses None (blank view).
l
To select a Node Group map you have created:
n
Prerequisite. Use the Node Group Map Settings configuration workspace to create
a Node Group map and enter a Topology Ordering number that lists the Node
Page 257 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
Group map as the first or last map in the Topology Maps workspace. See
"Configure Basic Settings for a Node Group Map" (on page 280) for more
information.
n
For the Initial View attribute:
o If you placed the Node Group map as the first entry in the Topology Maps
workspace, select First Node Group in Topology Maps workspace.
o If you placed the Node Group map as the last entry in the Topology Maps
workspace, select Last Node Group in Topology Maps workspace.
Dafault
Author
The Default Author attribute specifies the Author attribute NNMi should use by default when
you create a new instance of an object in NNMi. For example you might create a new
incident configuration.
The Author attribute identifies who provided that instance of an object. The Author attribute
value is also useful for filtering objects in certain views and when using the NNMi
Export/Import feature.
Either keep the Default Author value of Customer or enter an Author attribute value
representing you or your organization.
The Default Author value you specify then appears in the Author selection list in any
appropriate form and appears by default as the Author value when you create a new
instance of an object.
See Author form for important information.
Page 258 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
Enable
URL
Redirect
Before enabling URL Redirect, verify that the NNMi management server's official Fully
Qualified Domain Name (FQDN) is set correctly and the DNS name is resolvable from any
remote systems that need to access the NNMi management server. If the official FQDN
does not meet these requirements, users will view errors when trying to access the NNMi
console. To view the NNMi management server's official FQDN, do one of the following:
l
Select Help → System Information and click the Server tab.
l
Use the nnmhealth.ovpl command line tool.
l
Use the nnmofficialfqdn.ovpl command line tool.
Tip: To change the official FQDN, use the nnmsetofficialfqdn.ovpl command line tool.
When
URL Redirect is enabled, a user can sign into the NNMi console using any
hostname (not case-sensitive) or IP address that is valid for the NNMi management server.
(NNMi Advanced's Global Network Management feature or HP Network Node Manager i
Software Smart Plug-ins (iSPIs)) For environments configured with Single Sign-On (SSO)
among multiple servers (which normally requires users to provide the official Fully
Qualified Domain Name (FQDN) that was configured during NNMi installation), this
attribute enables NNMi to redirect URLs that contain the IP address or any hostname
associated with the NNMi management server to the official FQDN.
Note: All NNMi management servers participating in Global Network Management or
Single Sign-On (SSO) must have synchronized time stamps.
Show
Unlicensed
Features
By default, NNMi displays menus, views, and workspaces that require an additional
license. If you do not have the required license, NNMi labels these features as
Unlicensed or Evaluation. Evaluation indicates the License Type is Instant-On or
Temporary.
To determine which Unlicensed or Evaluation features could be displayed in your NNMi
console, click here for more information.
l
Access Help → Documentation Library → Release Notesand click the Licensing link.
l
Access Help → System Information and click the Extension tab.
l
Access Help → System Information and click the Product tab and click the View
Licensing Information button.
See "Purchase an HP Network Node Manager i Smart Plug-in" (on page 950) for more
information about possible HP Smart Plug-ins.
To hide Unlicensed or Evaluation features from the NNMi console, clear the Show
Unlicensed Features check box. (Recommended if you do not plan to install a
permanent license for these features.)
To display Unlicensed or Evaluation features in the NNMi console, select the Show
Unlicensed Features check box.
Registration Attributes for User Interface Configuration
Attribute
Description
Last Modified
Indicates the last date and time that any of the user interface attributes were modified.
Page 259 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
NNMi also enables you to configure features specific to Node Group Maps. See "Define Node Group Map
Settings" (on page 279) for more information.
Controlling Access to NNMi
As administrator, you control who accesses the NNMi console. The role you assign to each user
determines which workspaces and actions are available within the NNMi console. To accomplish this,
configure the following:
l
"Configure Sign-In Access" (on page 260)
l
"Disable a User's Access to NNMi (User Principals)" (on page 270)
l
"Troubleshoot NNMi Access" (on page 271)
l
"Set Up Command Line Access" (on page 273)
Tip: You can configure the NNMi management server to use https/SSL (secure sockets layer encryption)
so that data passed between client and server is encrypted. (See the "Enabling https for NNMi" chapter
in the HP Network Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals)
When configuration is complete, share information about NNMi with your team:
"Communicate to Your Team" (on page 275)
l
Configure Sign-In Access
First decide which pre-defined NNMi role is appropriate for each user in your environment:
"Roles Provided in NNMi" (on page 261)
l
Then choose how to configure access to the data required for NNMi logins:
1. "Control Access with NNMi Accounts" (on page 264)
User names, passwords, and role assignments are stored in the NNMi database.
2. "Control Access Using Both Directory Service and NNMi" (on page 266)
User names must be stored in both the directory service database and the NNMi database.
Passwords are stored in the directory service database. Role assignments are stored in the NNMi
database. NNMi communicates with the directory service using Lightweight Directory Access
Protocol (LDAP).
3. "Control Access with a Directory Service" (on page 269)
User names, passwords, and role assignments are stored in the directory service. NNMi
communicates with the directory service using Lightweight Directory Access Protocol (LDAP).
Which Database Stores the Information?
User Name
Password
Role Mapping
1
NNMi
NNMi
NNMi
2
Both
Directory Service
NNMi
3
Directory Service
Directory Service
Directory Service
Page 260 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Roles Provided in NNMi
As NNMi administrator, you assign a preconfigured NNMi role to each NNMi user. (For more information,
see "Configure Sign-In Access" (on page 260).)
User roles determine access to the NNMi console workspaces, forms, and actions. NNMi provides the
following roles:
l
Administrator
l
Operator Level 2
l
Operator Level 1
l
Guest
You cannot create additional roles or change the names of the roles that NNMi provides.
Caution: Do not use the system role. NNMi provides the system role for accessing NNMi the first time
during installation and for command line access (see "Set Up Command Line Access" (on page
273)).
NNMi provides a special Web Service Client role to provide access for software that is
integrated with NNMi (for example, see "HP RAMS MPLS WAN Configuration (NNMi Advanced)"
(on page 867)).
For details about roles, see the following topics:
l
"Determine which NNMi Role to Assign" (on page 261) (controls access to views and forms)
l
"Control Menu Access" (on page 262) (NNMi administrators control which roles can access a small
subset of Action menu items)
l
"Configure Basic Settings for a Node Group Map" (on page 280) (for each Node Group Map, the
Minimum Role for Saving Map Layout attribute setting controls the minimum user role required for
saving the layout after the user repositions nodes on the map)
Determine which NNMi Role to Assign
Before configuring NNMi sign-in access for your team, determine which predefined NNMi role is
appropriate for each team member. The roles are hierarchical, meaning the higher level roles include all
privileges of the lower roles in the hierarchy (Administrator is highest, Guest is lowest).
As NNMi administrator, you can change the following aspects of role definitions:
l
"Control Menu Access" (on page 262) (restrict access to certain NNMi Actions menu items and Tools
menu items - provide tighter security than those enforced by the default settings) See also "Configure
Launch Actions" (on page 876) for more information about adding options to the NNMi Actions menu.
l
"Configure Basic Settings for a Node Group Map" (on page 280). (for each Node Group Map, the
Minimum Role for Saving Map Layout attribute setting controls the minimum user role required for
saving the layout after the user repositions nodes on the map)
l
"Set Up Command Line Access" (on page 273) (control access to NNMi command line commands)
The following table lists the roles required to access NNMi workspaces. You cannot modify role settings for
workspaces. See About Workspaces for more information about workspaces. See Views Provided by
NNMi for more information about the views provided in each workspace.
Page 261 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Access to Workspaces
Workspaces
Guest
Role
Level 1
Operator
Role
Level 2 Operator
Role
Administrator
All views in the Incident workspaces
Yes
Yes
Yes
Yes
All views in the Topology workspaces
Yes
Yes
Yes
Yes
All views in the Monitoring workspace
Yes
Yes
Yes
Yes
All views in the Troubleshooting workspace
Yes
Yes
Yes
Yes
All views in the Inventory workspace
Yes
Yes
Yes
Yes
Yes
Yes
All views in the Management Mode
workspace
All views in the Configuration workspace
Yes
The following table provides some examples of how NNMi roles control permission for modifications to
certain forms. You cannot modify role settings for forms.
Access to Forms (some examples)
Guest
Role
Level 1
Operator
Role
Level 2
Operator
Role
Node forms
ReadOnly
Read-Write except Management Mode field
which is Read-Only
ReadWrite
Read-Write
Interface forms
ReadOnly
Read-Write except Management Mode field
which is Read-Only
ReadWrite
Read-Write
IP Address
forms
ReadOnly
Read-Write except Management Mode field
which is Read-Only
ReadWrite
Read-Write
IP Subnet
forms
ReadOnly
Read-Write except Management Mode field
which is Read-Only
ReadWrite
Read-Write
Incident forms
ReadOnly
Read-Write
ReadWrite
Read-Write
Node Group
forms
ReadOnly
Read-Only
ReadOnly
Read-Write
Forms
Configuration
Forms
Administrator
Read-Write
Control Menu Access
Access to the Tools and Actions menu items is controlled by user role. (See "Determine which NNMi Role
to Assign" (on page 261) for additional information about role limitations.)
Note the following:
Page 262 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
l
All menu items are visible to users, but an Access Denied message displays when any user with
insufficient privileges tries to use a menu item. For example, both Level 1 or Level 2 Operators are
denied access to the Communication Settings action.
l
You can restrict access to certain URL actions (provide tighter security than those enforced by the
default settings). See "Configure Menu Item Context Basic Details" (on page 875) for more information
about configuring actions.
Role Based Access the Tools Menu:
Access to the NNMi Tools menu items is determined by user role.
NNMi Tools Menu Access Limitations
Tools Menu Item
Default Role
Find Node
Guest
Find Attached Switch Port
Operator Level 2
Incident Actions Log
Administrator
Load MIB
Administrator
MIB Browser
Operator Level 2
NNMi Self-Monitoring Graphs
Administrator
NNMi Status
Operator Level 1
NNMi System Health Report
Adminstrator
Restore All Default View Settings
Guest
Signed In Users
Administrator
Sign In/Sign Out Audit Log
Administrator
Status Distribution Graphs
Operator Level 2
Trap Analytics (iSPI NET only)
Administrator
Upload Local MIB File
Adminstrator
Visio Export (iSPI NET only)
Operator Level 2
Role Based Access the Actions Menu:
Access to the NNMi Actions menu is determined by user role.
Page 263 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
URL Action Access Limitations
Action Menu Item
Default Role
Browse MIB
Operator Level 2
Communication Settings
Administrator
Configuration Poll
Operator Level 2
Graphs
Operator Level 1
List Supported MIBs
Operator Level 2
Management Mode
Operator Level 2
Monitoring Settings
Operator Level1
Ping (from server)
Operator Level 1
Show All Incidents
Guest
Show All Open Incidents
Guest
Show Attached End Nodes
Operator Level 2
Show Members
Guest
Status Details
Guest
Status Poll
Operator Level 2
Traceroute (from server)
Operator Level 1
Telnet...(from client)
Operator Level 2
See Investigate and Diagnose Network Problems for more information about these actions.
Control Access with NNMi Accounts
To configure NNMi to store user names, passwords, and role assignments in the NNMi database, use the
following instructions.
Which Database Stores the Information?
User Name
Password
Role Mapping
NNMi
NNMi
NNMi
Tip: If you prefer to configure NNMi logins to use data stored in the directory service database, see "Control
Access Using Both Directory Service and NNMi" (on page 266) or "Control Access with a Directory
Service" (on page 269).
To grant NNMi access to a user:
1. Navigate to the Account Mapping form.
a. From the workspaces navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
Page 264 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
c. Select the User Accounts tab.
d. Do one of the following:
o To create new configuration, click the
New icon, and continue.
o To edit an existing configuration, click the
Open icon in the row representing the
configuration you want to edit, and continue.
2. Locate the Account attribute, and click the
Form" for more information.)
n
To create new account, click the
Lookup icon. (See "Using the Account Mapping
New icon and provide the required user name and
password. See "Using the User Account Form" for more information.) Then click
Close to return to the Account Mapping form.
Save and
Tip: The user name you just created is added to the User Principals view.
n
To select an NNMi user configuration (user name and password), click the
and make a selection.
Quick Find icon
3. Locate the Role attribute.
Select a predefined NNMi role from the drop-down menu. See "Roles Provided in NNMi" (on page
261) for more information.
Note: If you accidentally assign two different NNMi roles to the same NNMi user name, NNMi uses
the higher level role.
4. Click
Save and Close to save your changes and return to the User Accounts form.
Related Topics
"Change Password, Name, or Role Assignment" (on page 265)
"Disable a User's Access to NNMi (User Principals)" (on page 270)
"Restore the Administrator Role" (on page 273)
Change Password, Name, or Role Assignment
If configuring NNMi to store user names, passwords, and role assignments in the NNMi database, use the
following instructions.
Which Database Stores the Information?
User Name
Password
Role Mapping
NNMi
NNMi
NNMi
Note: If configuring NNMi to use the directory service database, see "Change Role Assignment for a
Directory Service User Name" (on page 268) or "Control Access with a Directory Service" (on page
269).
Only NNMi administrators can change account details.
To change an NNMi user name:
You must "Disable a User's Access to NNMi (User Principals)" (on page 270), and then recreate the
Page 265 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
account mapping (see "Control Access with NNMi Accounts" (on page 264)).
Note: If you disable NNMi access for a user who is currently signed into the NNMi console, the change
does not take effect until the user signs in next time.
To change an NNMi password:
1. Navigate to the User Accounts view.
a. From the Workspaces navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Select the User Accounts tab.
2. Click the
Open icon in the row representing the account you want to edit.
3. To change the user's password, locate the Account attribute:
a. Click the
Lookup icon and select Open to access the User Account form.
b. Edit the Password value. Type up to 40 alpha-numeric characters, punctuation, spaces, and
underline characters.
c. Click
4. Click
Save and Close to return to the Account Mapping form.
Save and Close. NNMi immediately implements your changes.
Note: If you change the password for a user who is currently signed into the NNMi console, the
change does not take effect until the user signs in next time.
To change an NNMi role assignment:
1. Navigate to the User Accounts view.
a. From the Workspaces navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Select the User Accounts tab.
2. Click the
Open icon in the row representing the account you want to edit.
3. To change the user's NNMi role assignment, locate the Role attribute.
Click the drop-down list and select the new role for the current NNMi user. See "Determine which
NNMi Role to Assign" (on page 261) for more information about NNMi user roles and their privileges.
4. Click
Save and Close.
Note: If you change the role for a user who is currently signed into the NNMi console, the change
does not take effect until the user signs in next time.
Control Access Using Both Directory Service and NNMi
To configure NNMi to store role assignments in the NNMi database, but rely on your directory service for
user names and passwords, use the following instructions. NNMi communicates with the directory service
using Lightweight Directory Access Protocol (LDAP).
Which Database Stores the Information?
User Name
Password
Role Mapping
Both
Directory Service
NNMi
Page 266 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Tip: If you prefer to configure NNMi logins to only use data stored in the directory service database, see
"Control Access with a Directory Service" (on page 269).
To enable NNMi to communicate with your environment's directory service:
1. Modify the ldap.properties file. See the "Integrating NNMi with a Directory Service through LDAP"
chapter in the HP Network Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals
Note: To make changes to a user name or password, you must now use the appropriate process for
making changes to your environment's directory service software and make changes in NNMi
(see "Change Role Assignment for a Directory Service User Name" (on page 268)).
2. If you are switching from previously storing passwords in the NNMi database, do this step:
Note: The password information is no longer required to be in the NNMi database.
a. Navigate to the User Principals view:
i. From the workspace navigation panel, select the Configuration workspace.
ii. Select User Interface Configuration.
iii. Select the User Principals tab.
b. Delete all objects in the User Principals view:
i. Select all objects by clicking
ii. Click the
in the column heading row.
button in the view toolbar.
c. Navigate to the User Accounts view:
i. From the workspace navigation panel, select the Configuration workspace.
ii. Select User Interface Configuration.
iii. Select the User Accounts tab.
d. Verify that there are no remaining objects in this view. (When you deleted Principal objects,
any associated account objects were automatically removed.)
e. Continue with the next set of instructions.
3. Establish the NNMi role mappings for directory service users:
a. Navigate to the User Accounts view:
i. From the workspace navigation panel, select the Configuration workspace.
ii. Select User Interface Configuration.
iii. Select the User Accounts tab.
b. Repeat this step for each NNMi user.
Associate each user name from your environment's directory service with a predefined NNMi
role.
Click the
New icon. See "Using the Account Mapping Form".
Page 267 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
o Locate the Account attribute.
Click the
New icon. Enter the user name exactly as it appears in your environment's
directory service database (case-sensitive). See "Using the Principal Form" (on page
270).
Tip: The user name you just created is added to the User Principals view.
o Locate the Role attribute.
Select a predefined NNMi role from the drop-down menu. See "Roles Provided in NNMi"
(on page 261) for more information.
o Click
Save and Close to save your role configuration changes and return to the User
Accounts and Roles view.
c. Access the Incident Browsing workspace.
d. Open the All Incidents view.
Sort this view using the Assigned To (AT) column.
Verify that any assigned Incidents are associated with a valid user from the directory service
database.
o If the user names previously stored in the NNMi database are the same (case-sensitive)
as those defined in your environment's directory service, no changes are required for
Incident assignments.
o If the user names have changed, reassign the Incidents to a valid user name (see Assign
an Incident).
Change Role Assignment for a Directory Service User Name
If configuring NNMi to store user names and passwords in your environment's directory service, but to
store role assignments in the NNMi database, use the following instructions. NNMi communicates with the
directory service using Lightweight Directory Access Protocol (LDAP).
Which Database Stores the Information?
User Name
Password
Role Mapping
Both
Directory Service
NNMi
Note: To configure NNMi to use directory service for role assignments, see "Control Access with a
Directory Service" (on page 269).
Only NNMi administrators can change the role assigned to each authorized directory service user name.
To change an NNMi role assignment:
1. Navigate to the User Accounts view.
a. From the Workspaces navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Select the User Accounts tab.
2. Click the
Open icon in the row representing the mapping you want to edit.
3. Locate the Role attribute.
Page 268 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Click the drop-down list and select the new NNMi role for the current user. See "Determine which
NNMi Role to Assign" (on page 261) for more information about NNMi user roles and their privileges.
Note: If you accidentally assign two different NNMi roles to the same NNMi user name, NNMi uses
the higher level role.
4. Click
Save and Close.
Note: If you change the role for a user who is currently signed into the NNMi console, the change
does not take effect until the user signs in next time.
Control Access with a Directory Service
To configure NNMi to rely on your environment's directory service for role assignments, user names, and
passwords, use the following instructions. NNMi communicates with the directory service using
Lightweight Directory Access Protocol (LDAP).
Which Database Stores the Information?
User Name
Password
Role Mapping
Directory Service
Directory Service
Directory Service
Tip: If you prefer to configure NNMi to store the role assignments in the NNMi database, see "Control
Access Using Both Directory Service and NNMi" (on page 266).
To enable NNMi to communicate with your environment's directory service:
1. Modify the ldap.properties file. See the "Integrating NNMi with a Directory Service through LDAP"
chapter in the HP Network Node Manager i Software Deployment Reference, which is available at:
http://h20230.www2.hp.com/selfsolve/manuals
Note: To make changes to NNMi access (user name, password, or NNMi role assignment), you must
now use the appropriate process for making changes to your environment's directory service
software.
2. If you are switching from previously storing this data in the NNMi database:
a. Navigate to the User Principals view:
i. From the workspace navigation panel, select the Configuration workspace.
ii. Select User Interface Configuration.
iii. Select the User Principals tab.
b. Delete all objects in the view:
i. Select all objects by clicking
ii. Click the
in the column heading row.
button in the view toolbar.
c. Navigate to the User Accounts view:
i. From the workspace navigation panel, select the Configuration workspace.
ii. Select User Interface Configuration.
iii. Select the User Accounts tab.
d. Verify that there are no remaining objects in this view. (When you deleted Principal objects,
any associated Account Mapping and User Account objects were automatically removed.)
e. Access the Incident Browsing workspace.
Page 269 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
f. Open the All Incidents view.
Sort this view using the Assigned To (AT) column.
Verify that any assigned Incidents are associated with a valid user from the directory service
database.
o If the user names previously stored in the NNMi database are the same (case-sensitive)
as those defined in your environment's directory service, no changes are required for
Incident assignments.
o If the user names have changed, reassign the Incidents to a valid user name (see Assign
an Incident).
Disable a User's Access to NNMi (User Principals)
To deny a user's access to the console, delete their user configuration settings from the NNMi database.
Note: If you configured NNMi to store role assignments in your environment's directory service database
(not the NNMi database), ignore this topic. To disable a user's access to NNMi, use the appropriate
process required by your environment's directory service software (see "Control Access with a
Directory Service" (on page 269)).
Caution: If you delete the last NNMi user assigned to the Administrator role, no one can access the
Configuration workspace. See "Restore the Administrator Role" (on page 273) for more information
about how to recover from this mistake.
To deny a user's access to NNMi:
1. Navigate to the User Principals view.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Select the User Principals view.
2. Click
Show View in New Window.
NNMi displays the table view in a new window.
3. Check the
4. Click the
selection box that precedes the row containing their user name.
Delete icon.
The user's configuration is automatically removed from both the User Principals view and the User
Accounts view.
Tip: Access the Incident Browsing workspace. Open the All Incidents view. Sort this view using the
Assigned To (AT) column. Reassign all Incidents associated with any user you deleted (see Assign an
Incident).
Using the Principal Form
Principal object instances are automatically created when you configure access to the NNMi console
according to the following scenarios:
l
"Control Access with NNMi Accounts" (on page 264)
l
"Control Access Using Both Directory Service and NNMi" (on page 266)
Page 270 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Note: If NNMi role assignments are stored in your environment's directory service database, this form is not
needed. See "Control Access with a Directory Service" (on page 269).
To change a user name:
You must delete the Principal object and create a new one.
l
"Change Password, Name, or Role Assignment" (on page 265)
When user names, passwords, and role assignments are stored in the NNMi database.
Which Database Stores the Information?
l
User Name
Password
Role Mapping
NNMi
NNMi
NNMi
"Change Role Assignment for a Directory Service User Name" (on page 268)
When user names and passwords are controlled by the directory service, and role assignments are
stored in the NNMi database.
Which Database Stores the Information?
User Name
Password
Role Mapping
Both
Directory Service
NNMi
To delete a Principal object (deny access to the NNMi console):
See "Disable a User's Access to NNMi (User Principals)" (on page 270).
When you delete a Principal object, the user configuration is removed from both the User Principals view
and the User Accounts and Roles view.
Tip: If you delete an NNMi user, access the Incident Browsing workspace. Open the All Incidents view. Sort
this view using the Assigned To (AT) column. Reassign all Incidents associated with any user you
deleted (see Assign an Incident).
Troubleshoot NNMi Access
NNMi provides several tools to help you troubleshoot and monitor NNMi access:
l
"View the Users who are Signed In to NNMi" (on page 271)
l
"Audit NNMi User Activity" (on page 272)
l
"Restore the Administrator Role" (on page 273)
l
"Restore the System Role" (on page 273)
View the Users who are Signed In to NNMi
Use the Tools → Signed in Users menu option to view a list of the NNMi users who are currently signed in
to NNMi. This tool is useful when you want to determine which users and systems are available. For
example, you might want to view the users who are signed in before shutting down a system.
To see the list of users who are currently signed in to NNMi:
Select Tools → Signed In Users.
Page 271 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
NNMi displays the number of users currently signed in to NNMi as well as each user name, IP address of
the client that is running the NNMi console, and the time in which the user signed in to NNMi.
Audit NNMi User Activity
NNMi tracks a history of sign-in and sign-out activity for each NNMi user. This auditing information also
includes a variety of information about user activity since the NNMi management server was last restarted.
NNMi stores the audit log files in the following directory:
l
Windows:
%NnmDataDir%\log\nnm\
signin.0.0.log
l
UNIX:
/var/opt/OV/log/nnm/
signin.0.0.log
Note: Log files are consecutively numbered. A new file is created each time you restart the NNMi
management server. For example, <logFileName>.1.0.log and <logFileName>.2.0.log.
To see the most recent sign-in audit report:
1. A tool is available to NNMi administrators. In the console menu bar, select Tools → Sign In/Out Audit
Log.
2. The log provides a variety of information about recent account activity. For example:
Sign In/Sign Out Audit Log
Jun 14, 2007 10:53:01.926 AM [ThreadID:719] com.hp.ov.ui.util.
SignInOutAuditLog logSignIn:
INFO: Successful Sign In
User: system
Role: Administrator (ADMIN)
Remote Host: <node IP address>
Remote Port: 1549
Locale: en_US
Sign In/Out Audit Since 6/14/07 9:33 AM
=======================================
Currently Signed In:
#1: system <node IP address> 6/14/07 10:53 AM (last access 6/14/07 10:53 AM)
No users currently signed out.
To configure the behavior of sign-in information in the audit log files:
1. In a text editor, open the logging.properties file:
n
Windows:
%NnmDataDir%\shared\nnm\conf\ovjboss\logging.properties
n
UNIX:
/var/opt/OV/shared/nnm/conf/ovjboss/logging.properties
2. Optional. To disable sign-in and sign-out logging in the signin.0.0.log file, set
SignInOutAuditLog.level to OFF:
com.hp.ov.ui.util.SignInOutAuditLog.level = OFF
Page 272 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
3. Optional.To enable sign-in and sign-out logging in the signin.0.0.log file, set
SignInOutAuditLog.level to CONFIG:
com.hp.ov.ui.util.SignInOutAuditLog.level = CONFIG
4. Optional. To disable sign-in and sign-out logging in the nnmui.0.0.log file, set
SIgnInOutAuditLog.useParentHandlers to false:
com.hp.ov.ui.util.SIgnInOutAuditLog.useParentHandlers = false
5. Save and close the logging.properties file.
6. Before NNMi implements the change, you must follow the directions in the logging.properties
reference page (Help → Documentation Library → Reference Pages, in the File Formats category).
Restore the Administrator Role
If you have accidentally configured NNMi so that no one is assigned to the Administrator role
(preventing anyone from being able to access the Configuration workspaces), use the system user
account to correct the problem.
Sign into the console using the password that was configured for the system account when NNMi was
installed.
If you do not remember the password assigned to the system account, use the nnmchangesyspw.ovpl
command to reset the system password. See nnmchangesyspw.ovpl for more information.
Note: If you are still unable to sign into the console, verify that the nms-roles.properties file is in good
working order. See "Restore the System Role" (on page 273) for more information.
Restore the System Role
NNMi provides an nms-roles.properties file that stores the system role assignment. This file is
located in the following directory:
l
Windows:
%NnmInstallDir%\nonOV\jboss\nms\server\nms\conf\props\nms-roles.properties
l
UNIX:
/opt/OV/nonOV/jboss/nms/server/nms/conf/props/nms-roles.properties
You should not need to ever modify this file.
To verify the contents of this file:
1. With a text editor, open the nms-roles.properties file.
2. Verify that the following required line is present:
system=admin
3. Save and close the file.
Set Up Command Line Access
NNMi limits access to command line interface commands in one of two ways:
l
Requiring user name and password.
l
Requiring system role.
Page 273 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
See Help → Documentation Library → Reference Pages for a list of command line commands. Check
the appropriate Reference Page to determine which strategy applies.
Requiring User Name and Password
If you do not want to enter an NNMi User Name attribute value and an NNMi Password attribute value at
the command line, you can use the nnmsetcmduserpw.ovpl command to specify the valid user name and
password (instead of -u and -p). The credentials set using the nnmsetcmduserpw.ovpl command are
valid for command execution by the same user. See "Set Up Command Line Access" (on page 273) for
more information.
Requiring System Role
During installation, a special system user account is used to access NNMi for the first time. Thereafter, that
special account should be used only to use some command line interface commands and to "Restore the
Administrator Role" (on page 273).
Command line interface commands that required the system user account must be issued from the NNMi
management server, and you must have read access to the following files on the NNMi management
server:
1. nms-users.properties
2. nms-roles.properties
When you run a command line interface command that requires the system user account and you do not
specify a user name and password, note the following:
l
If you are logged in to the operating system as root user, NNMi is able to access the system account
information and runs the command line interface command using the system credentials.
l
If you are logged in to the operating system with a user name other than root and your user name is not
configured to access the system credentials, you are not able to run the command line interface
command.
Note: If you want a user other than root to access command line interface commands that require the
system role, use the nnmsetcmduserpw.ovpl command to reconfigure the User Account name and
password assigned to the NNMi system role.
Caution: Any user with read access to the nms-users.properties and nms-roles.properties files
can potentially change the NNMi system user account password. (UNIX: by default, only the root
user has read access to these files. Windows: by default, any user name that is associated with the
Administrators group has read access to these files.)
To configure read access to the nms-users.properties and nms-roles.properties files, follow the
operating system instructions for changing file access permissions.
l
Windows:
%NnmInstallDir%\nonOV\jboss\nms\server\nms\conf\props\nms-roles.properties
%NnmInstallDir%\nonOV\jboss\nms\server\nms\conf\props\nms-users.properties
l
UNIX:
/opt/OV/nonOV/jboss/nms/server/nms/conf/props/nms-roles.properties
/opt/OV/nonOV/jboss/nms/server/nms/conf/props/nms-users.properties
See "Restore the Administrator Role" (on page 273) and "Restore the System Role" (on page 273) for
more information about the system user account's role and password.
Page 274 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Communicate to Your Team
After configuring user passwords and roles, communicate the following information to your team:
l
"Open the Console" (on page 275)
l
"Sign Into the NNMi Console" (on page 276)
l
"Sign Out from the Console" (on page 276)
Open the Console
Provide each user with the following information:
Note: If the NNMi Web server uses the https protocol, use https instead of http. (See the"Enabling https
for NNMi" chapter in the HP Network Node Manager i Software Deployment Reference, which is
available at: http://h20230.www2.hp.com/selfsolve/manuals)
http://<serverName>:<portNumber>/nnm/
<serverName> = the fully-qualified domain name of the NNMi management server (values allowed here
are determined by the Enable URL Redirect setting in User Interface Configuration, see
"Configuring the NNMi User Interface" (on page 257))
<portNumber> = the port that the jboss application server uses for communicating with the NNMi console
When your NNMi management server has more than one fully-qualified domain name, NNMi chooses one
during the installation process. There are two ways to find out which domain name NNMi is using in your
network environment:
l
Click Help → System Information and navigate to the Server tab. Locate the Official Fully Qualified
Domain Name (FQDN) attribute value.
l
Use the nnmofficialfqdn.ovpl command. See the nnmofficialfqdn.ovpl Reference Page.
To determine the current port number configuration, look at the line for boss.http.port in the nmslocal.properties file (see table for the location of this file). See the nnm.ports Reference Page for more
information.
Determine the NNMi Console Port Number
Operating System
Identify Current Port Number
Windows
%NnmDataDir%\conf\nnm\props\nms-local.properties
UNIX
/var/opt/OV/conf/nnm/props/nms-local.properties
Communicate the following browser requirements for your team to use the NNMi console:
l
Use Microsoft Internet Explorer 7.0 or later or Mozilla Firefox 2.0 or later.
l
Pop-ups, cookies, and JavaScript must be enabled.
l
Each user's screen resolution must be 1024x768 pixels or higher.
l
When using Microsoft Internet Explorer as your browser, you can access multiple browser sessions of
NNMi. Use a different user name for each browser session.
l
When using Mozilla Firefox as your browser, multiple browser sessions all point to the same window.
Page 275 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Note: Users can bookmark the URL for the NNMi console. Use the URL for the NNMi console rather than
the NNMi Welcome page. See About the NNMi Console for more information about the NNMi
console.
To open the console:
1. Type the following URL (Uniform Resource Locator) into your browser navigation bar:
http://<serverName>:<portNumber>/nnm/
2. Sign in with the following name and password:
<name you configured>
<password you configured>
Note: The sign-in prompt cannot be disabled, but you can include name and password in the URL.
See "Launch the Console (showMain)" (on page 955).
3. Click the Sign In button. (See "Sign Into the NNMi Console" (on page 276) if you need more
information.)
4. The console opens in a new window.
5. Optional. Close the NNMi Welcome page.
Note: If you do not close the NNMi Welcome page or sign out, you can relaunch the console from the
NNMi Welcome Page without signing in again.
To refresh the console window:
Click the
Refresh icon in the tool bar of any NNMi window.
Sign Into the NNMi Console
After entering the URL for the console, users are prompted for a user name and password.
To sign into the Console:
1. At the User Name prompt, enter the assigned user name.
2. At the Password prompt, enter the currently assigned password.
3. Click the Sign In button.
Each user name is assigned to an NNMi role. The role determines what users can do with the NNMi
console. "Determine which NNMi Role to Assign" (on page 261) for more information.
The user name and the associated role appear in the upper right corner of the console as shown in the
example below:
Sign Out from the Console
To sign out from the console:
Page 276 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
1. Select File → Sign Out.
2. Click OK.
Note the following:
l
Sign in is not preserved across user sessions. After signing out, each user must sign in again.
l
You must sign out of each browser session that is running NNMi. For example, if you have signed in
twice with two different browsers, signing out in one browser does not cause you to lose access in the
other browser.
l
NNMi automatically signs out any user after four hours of inactivity.
Configure Maps
NNMi enables you to configure the following maps:
l
Node Group Map views
l
Path View Maps
Note: The Node Group Overview map provided by NNMi is not configurable.
When configuring Node Group maps, you can do the following:
l
Include only the nodes that are important to you.
l
Specify which Node Group maps appear in the Topology Maps workspace.
l
Specify refresh information.
l
View node groups in the context of a relevant background image, such as a map illustrating node
locations.
l
View node groups in a customized arrangement.
When configuring Node Group map views, you can also specify the role level required to save maps in a
customized arrangement. See "Define Node Group Map Settings" (on page 279) for more information.
When configuring Path View maps you specify undiscovered regions of your network by creating a
PathConnections.xml file that defines the path between the undiscovered nodes. See"Configure a
Path View Map" (on page 289) for more information.
You can also specify the maximum number of nodes to display on a map. See "Define Default Map
Settings" (on page 277) for more information.
Related Topics
"Node Group Map Settings Form" (on page 279)
Node Group Map View
Position Nodes in a Node Group Map
Define Default Map Settings
Default Map Settings define settings for all of your Node Group Maps.
Note: You can override Default Map Setting using the Node Group Map Settings Configuration
workspace. See "Configure Basic Settings for a Node Group Map" (on page 280) for more
information.
Page 277 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
To configure Default Map Settings, do the following:
1. Navigate to the User Interface Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
2. Navigate to the Default Map Settings tab.
3. Make your configuration choices (see the Default Map Settings Attributes table).
4. Click
Save and Close to return to the User Interface Configuration form.
5. Click
Save and Close to save and apply your changes.
Default Map Settings Attributes
Attribute
Description
Map Refresh
Interval
Specifies the refresh interval for Status Refresh.
Maximum
Number of
Displayed
Nodes
Use this attribute to change the maximum number of nodes to be displayed on a map.
Note the following:
l
If you change the default value to display a large number of nodes at one time, you
might need to re-adjust this number if maps are taking longer than expected to
display.
l
In Layer 2 and Layer 3 Neighbor views, NNMi adds nodes one hop at a time. If
NNMi finds a large number of nodes in a single hop, the number of nodes might
exceed the maximum number specified.
Maximum
Number of
Displayed End
Points
Use this attribute to change the maximum number of end points to be displayed on a
map.
Multiconnection
Threshold
Use this attribute to change the number of connections that must exist between two
objects before NNMi displays the connections as one thick line on a map (known as a
multiconnection).
Note: If you change the default value to display a large number of end points at one
time, you might need to re-adjust this number if maps are taking longer than
expected to display.
When this number of connections is reached, NNMi displays the connections as one
thick line on all maps except Path View maps.
Note: To display the Interface objects and each connection, double-click the line
representing the multiconnection.
Indicate Key
Incidents
In the Node Group map, users can click the
view toolbar to toggle this feature on and off.
Indicate Key Incidents icon in the map
When enabled , when the this Node Group map opens, NNMi enlarges any objects
on a Node Group map that are Source Objects for a Key Incident1. (For example,
1Incidents with both: (1) Severity = other than Normal. (2) Correlation Nature = equal to Root Cause,
Service Impact, Stream Correlation, Rate Stream Correlation, Info, or None.
Page 278 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
when viewing the Node Group map, NNMi enlarges any node on a Node Group map
that has an open root cause incident associated with it.)
When disabled , when the this Node Group map opens, NNMi does not indicate the
objects on a Node Group map that are Source Objects for a Key Incident1.
You can override this setting for a particular Node Group map, when you "Configure
Basic Settings for a Node Group Map" (on page 280). When viewing the Node Group
map, you can also enable or disable this feature. See Node Group Maps and Key
Incident Views for more information.
Define Node Group Map Settings
Node Group Map settings specify the node group and background image to be used in a Node Group
map. Map settings include the following:
l
Node group name
l
Topology Maps Workspace ordering
l
Minimum role for saving edited locations for each node in the map
l
Refresh interval
l
The maximum number of map nodes
l
Node connectivity information
l
Node Group connectivity information
l
Background image information
Node Group Map views are used for a variety of purposes in NNMi:
l
Viewing groups of only the nodes that are important to you.
l
Viewing Node Groups in the context of a relevant background image.
l
Viewing Node Groups in a customized arrangement.
To define Node Group Map Settings, use the "Node Group Map Settings Form" (on page 279).
To view a Node Group Map, use the Actions menu from the NNMi main toolbar from either a Node Group
or Node Group Map Settings. See Node Group Map for more information.
To view more information about the Node Group from a Node Group map, use the File → Open Node
Group for Map option to open the Node Group form for the selected Node Group.
Node Group Map Settings Form
Use the Node Group Map Settings form to configure maps based on currently defined Node Groups. Items
you configure include the background image and type of connectivity (for example, Layer 2) to be
displayed on the map.
1Incidents with both: (1) Severity = other than Normal. (2) Correlation Nature = equal to Root Cause,
Service Impact, Stream Correlation, Rate Stream Correlation, Info, or None.
Page 279 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Note: NNMi displays the list of Node Group Map Settings that have default configuration changes. If NNMi
does not display a list of Node Group Map Settings, this means that NNMi is using the default
settings for each Node Group Map. To change the default settings for a Node Group Map, either
Save Layout from the Node Group Map
reposition the nodes on the map of interest and select
toolbar or use the Node Group Map Settings form to create a Node Group Map Settings
configuration as described below. See Position Nodes on a Node Group Map for more information
about using
Save Layout.
To configure Node Group Map Settings, do the following:
1. Navigate to the Node Group Map Settings Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Navigate to the Node Group Map Settings tab.
d. Do one of the following:
o To create a new configuration, click the
New icon, and continue.
o To edit an existing configuration, click the
Open icon in the row representing the Node
Group Map Settings definition you want to edit, and continue.
2. Make your configuration choices (see table).
3. Click
Save and Close to save and apply your changes.
Note: You can also access the Node Group Map Settings form from a Node Group Map using the File →
Open Node Group Map Settings option.
Tasks for Configuring Node Group Map Settings
Task
How
"Configure Basic
Settings for a Node
Group Map" (on page
280)
Use the Basics Settings pane to configure Node Group, Topology Maps, and
Refresh Interval information.
"Configure the
Connectivity to be
Displayed for a Node
Group Map" (on page
284)
Use the Connectivity tab to configure the level of node connectivity to be
displayed on the Node Group Map. Use this tab to also specify the Node Group
connectivity to be displayed and maximum connections to be included on the
Node Group map.
"Configure
Background Image
Information for a
Node Group Map"
(on page 285)
Use the Background Image tab to configure information about the Background
Image to use on the Node Group map.
Note: To apply your Topology Maps Ordering configuration changes, sign out of
the NNMi console. After restarting the console, your changes should take
affect. Possible configuration changes include reordering a Node Group
map view or adding a new Node Group map view to the workspace.
Configure Basic Settings for a Node Group Map
The Basic Settings configuration determines general information about the Node Group map.
To establish Basic Settings for a Node Group Map:
Page 280 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
1. Navigate to the Node Group Map Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Select the Node Group Map Settings tab.
d. Do one of the following:
o To create a Node Group Map Settings definition, click the
New icon.
o To edit a Node Group Map Settings definition, click the
Open icon in the row that
represents the Node Group Map Settings definition you want to edit.
o To delete a Node Group Map Settings definition, select a row and click the
Delete
button
2. Establish the appropriate settings to identify Node Group and Refresh Settings information (see
tables).
3. Click
Save and Close to save and apply your changes.
Basic Attributes
Attribute
Description
Node Group
Specifies which parent node group to display in the Node Group Map view. The
contents of the parent node group include any nodes and Child Node Groups
associated with it.
Note: NNMi displays any Child Node Groups of the selected parent Node Group as a
hexagon on the map.
The Expand Child in Parent Node Group Map attribute determines how a Child Node
Group appears on the Node Group Map. Expand Child in Parent Node Group Map is
disabled by default.
l
If the Child Node Group has the Expand Child in Parent Node Group Map attribute
disabled, the Child Node Group appears as a hexagon on the map as shown
below:
l
If any Child Node Group has the Expand Child in Parent Node Group Map
attribute enabled, NNMi instead recursively displays each of the nodes in that
Child Node Group on the map.
See Node Group Form: Child Node Groups Tab for more information about configuring
Child Node Groups.
Page 281 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
Topology Maps
Ordering
Use this attribute to specify the order in which you want the Node Group map to
appear in the Topology Maps workspace.
Note: If you do not want this Node Group map to appear in the Topology Maps
workspace, leave the value blank.
See Views Provided by NNMi for more information about the maps provided in the
Topology Maps workspace.
Note: To apply your Topology Maps Ordering configuration changes, sign out of the
NNMi console. After restarting the console, your changes should take affect.
Possible configuration changes include reordering a Node Group map view or
adding a new Node Group map view to the Topology Maps workspace.
Page 282 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
Minimum Role
for Saving Map
Layout
Controls the minimum user role required to save the layout of repositioned nodes in a
Node Group Map. This value also controls the minimum user role for configuring Node
Group Map Settings.
Note: Only a user with the role of Administrator can set the Minimum Role for Saving
Map Layout value.
Possible values include:
l
Administrator
l
Operator Level 2
l
Operator Level 1
The default value is Administrator. See "Determine which NNMi Role to Assign" (on
page 261)for more information about NNMi roles.
Note: A user with any role can initially reposition nodes on a Node Group Map view.
However, unless your user name is assigned to the required minimum role, you
cannot save the new node locations on the map. After being saved, these node
positions are seen by any user opening this Node Group Map.
Map Refresh
Interval
Specify the Refresh Interval you want to use in days, hours, minutes, and seconds. By
default, the Refresh Interval is 30 seconds. This interval is used to set the Refresh
Status interval for this map if it is used.
Maximum
Number of
Displayed
Nodes
Specifies the maximum number of nodes to be displayed on the Node Group map.
Maximum
Number of
Displayed End
Points
Specifies the maximum number of end points to be displayed on a map.
Multiconnection
Threshold
Use this attribute to change the number of connections that must exist between two
Node Groups before NNMi displays the connections as one thick line (known as a
multiconnection) on a Node Group map.
Note: This number applies to the total number of nodes within the Node Group,
including any Child Node Groups displayed on the map.
Note: If maps are taking longer than expected to display, you might need to re-adjust
this number.
Note the following:
l
The value you enter overrides the Multiconnection Threshold set using the Default
Map Settings.
l
If this setting is blank, NNMi uses the Multiconnection Threshold value configured
in Default Map Settings.
l
When this number of connections is reached, NNMi displays the connections as
one thick line.
l
To display the Interface objects and each connection, double-click the line
representing the multiconnection.
Page 283 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
Indicate Key
Incidents
In the Node Group map, users can click the
view toolbar to toggle this feature on and off.
Indicate Key Incidents icon in the map
When enabled , when the this Node Group map opens, NNMi enlarges any objects
on a Node Group map that are Source Objects for a Key Incident1. (For example,
when viewing the Node Group map, NNMi enlarges any node on a Node Group map
that has an open root cause incident associated with it.)
When disabled , when the this Node Group map opens, NNMi does not indicate the
objects on a Node Group map that are Source Objects for a Key Incident2.
Include in Visio
Export
When enabled , NNMi includes this map when exporting all saved Node Group
maps using the Tools → Visio Export (iSPI NET only)→ Saved Node Group Maps
option.
When disabled , NNMi does not include this map when exporting all saved Node
Group maps using the Tools → Visio Export (iSPI NET only) → Saved Node Group
Maps option.
Configure the Connectivity to be Displayed for a Node Group Map
The Connectivity Tab of the Node Group Map Settings form enables you to specify the level of connectivity
to be displayed on the Node Group map. You also specify the connections that you want to display.
1. Navigate to the Connectivity tab of the Node Group Map Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Select the Node Group Map Settings tab.
d. Do one of the following:
o To create a Node Group Map Settings definition, click the
New icon.
o To edit a Node Group Map Settings definition, click the
Open icon in the row
representing the Node Group Map Settings definition you want to edit.
o To delete a Node Group Map Settings definition, select a row and click the
Delete
button
e. d. Select the Connectivity tab.
2. Configure the connectivity information for this Node Group Map Settings definition (see table).
3. Click
Save and Close to save and apply your changes.
1Incidents with both: (1) Severity = other than Normal. (2) Correlation Nature = equal to Root Cause,
Service Impact, Stream Correlation, Rate Stream Correlation, Info, or None.
2Incidents with both: (1) Severity = other than Normal. (2) Correlation Nature = equal to Root Cause,
Service Impact, Stream Correlation, Rate Stream Correlation, Info, or None.
Page 284 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Connectivity Attributes
Attribute
Description
Connectivity
Type
Connectivity Type determines the type of connectivity to display between nodes in the
Node Group Map view.
By default, NNMi displays the Layer 2 connectivity between nodes when displaying a
Node Group Map view. Possible values include:
l
None - Choose this if you do not want any connectivity displayed on the map.
l
Layer 2 - Uses Layer 2 connectivity when displaying devices in a Node Group Map
view. This connectivity is used by default when positioning node locations on a Node
Group Map.
l
Layer 3 - Uses Layer 3 connectivity when displaying devices on a Node Group Map
view.
See Position Nodes on a Node Group Map for more information.
Add L2
Subnet
Connections
If you specify Layer 3 or None as the Connectivity Type, this option specifies that you
want to include any subnet connections determined by Subnet Connections Rules.
Add L2 User
Connection
Edits
If you specify Layer 3 or None as the Connectivity Type, specifies that you want to include
any Layer 2 connections added using the NNMi nnmconnedit.ovpl command to add or
delete connection data.
See "Configure Subnet Connection Rules" (on page 150) for more information.
See "Add or Delete a Layer 2 Connection" (on page 174) for more information.
Interface
Group
Use this option, if you want to reduce the connectivity endpoints on the Node Group Map.
The Interface Group you select defines the Interface Group to which an interface must
belong to be used to connect a Node Group to a Node Group or a Node to a Node Group.
NNMi displays Layer 2 endpoints that are interfaces in the group. NNMi displays Layer 3
endpoints that are IP addresses associated with interfaces in the group.
Nodes to
Node Group
Select this check box if you want Node to Node Group connectivity to appear on the Node
Group map.
Note: By default, this option is not enabled.
Node
Groups to
Node
Groups
Select this check box if you want Node Group to Node Group connectivity to appear on
the Node Group map.
Note: By default, this option is not enabled.
Configure Background Image Information for a Node Group Map
Use the Background Image tab of the Node Group Map Settings form to configure information about the
Background Image to use on the Node Group map.
1. Navigate to the Background Image tab of the Node Group Map Settings form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select User Interface Configuration.
c. Select the Node Group Map Settings tab.
Page 285 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
d. Do one of the following:
o To create a Node Group Map Settings definition, click the
New icon.
o To edit a Node Group Map Settings definition, click the
Open icon in the row
representing the Node Group Map Settings definition you want to edit.
o To delete a Node Group Map Settings definition, select a row and click the
Delete
button
2. Establish the appropriate settings to identify the Background Image information (see table ).
3. Click
Save and Close to save and apply your changes.
Background Image Attributes
Attribute
Description
Background
Image
Enter the URL for the background image you want to use for this Node Group Map. You
can use a background image provided by NNMi or add your own.
Note: Click Background Image to view the map.
Use a Background Image Provided by NNMi
NNMi provides a set of background images that include maps of many countries. If you
want to use one of those images, append the location and file name to the URL at which
you access the NNMi console. Use the format: /nnmbg/<file name>. For example:
/nnmbg/colorado.gif
To see all of the available images provided by NNMi, browse to:
http://<serverName>:<portNumber>/nnmbg/
<serverName> = the fully-qualified domain name of the NNMi management server
(values allowed here are determined by the Enable URL Redirect setting in User
Interface Configuration, see "Configuring the NNMi User Interface" (on page 257))
<portNumber> = the port that the jboss application server uses for communicating with
the NNMi console
Use a Background Image You Provide
You can also provide your own images. See "Background Image Sources in Node Group
Maps" (on page 288) for more information about where to load the background images
you want to use.
To see a list of all the images added to NNMi, access the following URL:
http://<serverName>:<portNumber>/nnmdocs/images/
To use an image that has been added to NNMi, use the following URL:
/nnmdocs/images/<file name>
For example: /nnmdocs/images/myimage.gif
Note the following:
l
NNMi accepts images that can be loaded by a Web browser. Common file extensions
include: .gif, .png and .jpg.
l
Image names are case sensitive. All background image file names provided by NNMi
Page 286 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
are lowercase.
l
Do not use http://<localhost> in your URL. This implies the image is on your local
machine and is not available from other clients.
l
If using full URLs, all client machines must be able to resolve the DNS hostname of
the server on which the images reside.
l
When you pan and zoom around the map, the background image moves in relation
with the other objects on the map.
If the image does not display, see "Troubleshoot URLs When Specifying a Background
Image" (on page 289) for more information.
Page 287 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
Background
Image
Scale
The Background Image Scale attribute applies to the actual background image
dimensions when displayed on a Node Group Map.
Enter a floating point number greater than zero (0.0) to indicate the ratio at which you
want NNMi to scale the background image. For example, the value 1.0 represents a oneto-one ratio, resulting in a background image displayed at actual size. A value of 2.0
represents a two-to-one ratio, resulting in a background image displayed at twice the
actual size.
Note: The default ratio value is 1.0. (This means no scaling is applied.) Use this default
value initially. You can adjust it as needed based on the relative size between the
image and nodes.
See "Scale Background Images in Node Group Maps" (on page 289) for guidelines for
scaling the background images you specify.
Background Image Sources in Node Group Maps
When specifying background images to include in Node Group Maps, NNMi enables you to use images
provided by NNMi or images that you provide.
The images that NNMi provides include maps of many countries.
To see the available images provided by NNMi:
Browse to: http://<serverName>:<portNumber>/nnmbg/
<serverName> = the fully-qualified domain name of the NNMi management server (values allowed here
are determined by the Enable URL Redirect setting in User Interface Configuration, see
"Configuring the NNMi User Interface" (on page 257))
<portNumber> = the port that the jboss application server uses for communicating with the NNMi console
To use your own background images:
Place you user-supplied images in the following directory:
Windows:
%NnmDataDir%/shared/nnm/www/htdocs/images
Unix:
/var/opt/OV/shared/nnm/www/htdocs/images
NNMi accepts images that can be loaded by a Web browser. Common file extensions include: .gif, .png
and .jpg.
To see the available images that have been added to NNMi:
Access the following URL: http://<serverName>:<portNumber>/nnmdocs/images
<serverName> = the fully-qualified domain name of the NNMi management server (values allowed here
are determined by the Enable URL Redirect setting in User Interface Configuration, see
"Configuring the NNMi User Interface" (on page 257))
<portNumber> = the port that the jboss application server uses for communicating with the NNMi console
Page 288 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
See "Node Group Map Settings Form" (on page 279) for more information about how to configure Node
Group Maps to use background images.
Scale Background Images in Node Group Maps
Scale a specified background image for a Node Group Map using the Background Image Scale attribute.
See "Define Node Group Map Settings" (on page 279) for more information.
When you use the maps provided by NNMi, it is recommended that you initially use the default value of 1.0
for the Background Image Scale.
When you use your own images for map backgrounds and you are selecting a scale value, consider the
following:
l
NNMi renders its nodes 50 by 50 pixels. This means if your image is 500 pixels wide, there is room for
10 nodes across the image.
l
To display the image at normal resolution, enter a scale value of 1.0. (This means no scaling occurs.)
l
After the image displays on the map, look at the relationship between the node size and the
background to determine whether you need to rescale the background image:
n
If the nodes look too large compared to the background, enlarge the image using a scale value
greater than 1.0.
n
If the nodes look too small compared to the background, make the image smaller using a scale
value less than 1.0.
Troubleshoot URLs When Specifying a Background Image
This topic contains troubleshooting steps to use if your background image does not display.
Note: If the NNMi Web server uses the https protocol, use https instead of http. (See the"Enabling https
for NNMi" chapter in the HP Network Node Manager i Software Deployment Reference, which is
available at: http://h20230.www2.hp.com/selfsolve/manuals)
If you used a relative URL (beginning with a slash (/) in the Background Image attribute value:
1. Copy and paste the URL to a browser.
2. Insert http://<serverName>:<portNumber> in front of the slash (/).
<serverName> = the fully-qualified domain name of the NNMi management server (values allowed
here are determined by the Enable URL Redirect setting in User Interface Configuration, see
"Configuring the NNMi User Interface" (on page 257))
<portNumber> = the port that the jboss application server uses for communicating with the NNMi
console
If you used an absolute URL (beginning with http://) in the Background Image attribute value:
Copy and paste the URL to a browser.
Configure a Path View Map
Configuring a Path View map is useful when you have two or more areas of your network which are
separated by undiscovered devices, such as service provider nodes. NNMi enables you to configure a
Page 289 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Path View map that traverses undiscovered regions of your network. To configure this kind of Path View
map, create a PathConnections.xml file that defines the following:
l
Required. A Start node for each <CONNECT> to be included in the Path View map
l
Optional. A unique identifier for a <CONNECT>
l
Optional. The outbound interface from each Start node per <CONNECT>
l
Required. Any number of undiscovered nodes you want to be included in the map between each
<CONNECT>
l
Optional. An End node for a <CONNECT> to be included in the Path View map
l
Optional. The inbound interface to each End node per <CONNECT> specified.
Each time NNMi determines a node in the Path View, NNMi checks whether the node is specified as a
Start node in the PathConnections.xml file. If the node is specified as a Start node in
PathConnections.xml, each <CONNECT> configured in PathConnections.xml is inserted in the Path
View map.
Note: NNMi Advanced. NNMi can use RAMS data to determine router paths. When RAMS data is used to
determine the router paths, NNMi ignores the PathConnections.xml file. See Path View with
NNMi Advanced for more information.
Note: NNMi Advanced. Path View works only with IPv4 addresses. The NNMi Advanced IPv6 address
values are not valid choices for Path View. Any devices in your network that are configured with
IPv6 addresses cannot be displayed on Path View maps.
To configure a Path View map:
Using the required format, create a PathConnections.xml file in the following location:
Windows:
%NnmDataDir%/shared/ nnm/conf/PathConnections.xml
UNIX:
/var/opt/OV/shared/nnm/conf/PathConnections.xml
The following table describes each of the file elements and its format requirements. (Also see the sample
file)
Note: Each segment of the path that you specify using the <CONNECT> element is directional. If you want to
view the path between two nodes in both directions, make sure you include the Start and End nodes
for each direction. You should also include the inbound interface for the Start node. If you do not
limit the possible routers by including the inbound interface for the Start node, Path View might find
additional routers in the path.
Elements for the Path View Configuration File
Element Descriptions
<CONNECTIONS>
Required parent element. The file must include only one <CONNECTIONS> element.
<CONNECT>
Specifies a segment of the path. Each <CONNECT> designates a start and stop location for the
<CONNECT>.
The file can include more than one <CONNECT> element.
<ID>
C1
Page 290 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Element Descriptions
</ID>
Optional. Identifies the connection. NNMi uses the ID value you enter when reporting errors for a
<CONNECT>.
If you do not provide an ID value for the path between a Start and End node, any error message for the
<CONNECT> displays Not Applicable rather than the unique identification value.
<START>
<IP_OR_DNS>xxx.xx.xxx.x</IP_OR_DNS>
<OUTBOUND_INTERFACE_IFINDEX>x</OUTBOUND_INTERFACE_IFINDEX>
<NEXT_HOPS>
<HOP>xxx.xx.xxx.x</HOP>
<HOP>xxx.xx.xxx.x</HOP>
</NEXT_HOPS>
</START>
Specifies the node where a segment of the path starts. You provide values for the following elements:
l
<IP_OR_DNS> provides the name or IPv4 address of a node in your network. See "Configure the
Node Name Strategy" (on page 138) for more information about node names.
l
Optional. <OUTBOUND_INTERFACE_IFINDEX> designates which of the Start node's interfaces to use
for this segment of the path.
l
<NEXT_HOPS> designates one or more specific IPv4 addresses or nodes that you want to be
included in the path.
<END>
<IP_OR_DNS>xxx.xx.xxx.x</IP_OR_DNS>
<INBOUND_INTERFACE_IFINDEX>x</INBOUND_INTERFACE_IFINDEX>
</END>
Specifies the node where the <CONNECT> ends. You provide values for the following elements:
l
<IP_OR_DNS> provides the name or IPv4 address of a node in your network.
l
Optional.<INBOUND_INTERFACE_IFINDEX> designates which of the End node's interfaces to use for
this segment of the path.
</CONNECT>
Required. Designates the end of the XML code that defines one segment of your path view.
</CONNECTIONS>
Required parent element. Designates the end of the XML code that defines your path view.
Click here to view a sample file:
<?xml version="1.0" encoding="UTF-8"?>
<CONNECTIONS>
<CONNECT>
<ID>
C1
</ID>
<START>
<IP_OR_DNS>StartNode.xx.xxx.x</IP_OR_DNS>
Page 291 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
<OUTBOUND_INTERFACE_IFINDEX>3</OUTBOUND_INTERFACE_IFINDEX>
<NEXT_HOPS>
<HOP>hop-1.xxx.xx.xxx</HOP>
<HOP>hop-2.xxx.xx.xxx</HOP>
</NEXT_HOPS>
</START>
<END>
<IP_OR_DNS>EndNode.xxx.xx.xxx</IP_OR_DNS>
<INBOUND_INTERFACE_IFINDEX>6</INBOUND_INTERFACE_IFINDEX>
</END>
</CONNECT>
</CONNECTIONS>
When viewing Path View maps that are configured using the PathConnections.xml file, note the
following:
l
If the <END> element is not specified, NNMi connects directly to the Destination node to complete the
path.
l
If the <END> element is specified, then the associated <IP_OR_DNS> specifies a discovered node as
the End node of this segment of your Path View.
Click here to view the sample Path View map generated from the sample file above.
Click here to view a sample file that includes both directions for the sample Path View map above.
Note: In this example, the path is the same in both directions. In many cases, the path might be different in
each direction.
<?xml version="1.0" encoding="UTF-8"?>
<CONNECTIONS>
<CONNECT>
<ID>
C1
</ID>
<START>
<IP_OR_DNS>StartNode.xx.xxx.x</IP_OR_DNS>
<OUTBOUND_INTERFACE_IFINDEX>6</OUTBOUND_INTERFACE_IFINDEX>
<NEXT_HOPS>
<HOP>hop-1.xxx.xx.xxx</HOP>
<HOP>hop-2.xxx.xx.xxx</HOP>
</NEXT_HOPS>
</START>
<END>
<IP_OR_DNS>EndNode.xxx.xx.xxx</IP_OR_DNS>
<INBOUND_INTERFACE_IFINDEX>3</INBOUND_INTERFACE_IFINDEX>
</END>
</CONNECT>
</CONNECTIONS>
Page 292 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Click here to view the sample Path View map generated from the sample file above after clicking the
Swap Nodes button.
Configure Default Settings for Line Graph
NNMi enables you to configure default settings for Line Graphs displayed through the Actions menu.
Note: NNMi provides a set of Line Graphs for node and interface objects that are accessible from the
Actions menu. As an NNMi administrator you can configure additional Line Graphs using the Menu
Items tab of the User Interface Configuration form. See "Configure SNMP Line Graph Actions" (on
page 888) for more information.
To configure default settings for Line Graphs:
1. Navigate to the Configuration workspace.
2. Select User Interface Configuration.
3. Navigate to the Default Line Graph Settings tab.
4. Provide the default settings for all Line Graphs (see the Default Line Graph Settings table).
5. Click
Save and Close to the User Interface Configuration form.
6. Click
Save and Close to save and apply your changes.
Default Line Graph Settings
Attribute
Description
Default
Polling
Interval
(Seconds)
The Default Polling Interval determines how often the NNMi management server polls for
the most recent set of data points to be displayed in a Line Graph.
Note: This Default Polling Interval does not affect the polling intervals set for the NNMi State
Poller.
Enter the number of seconds in which NNMi should poll for graph data.
If you do not specify an Polling Interval, NNMi determines the best setting for the Polling
Interval based on the Maximum Time Range specified.
If you do not specify an Polling Interval and you do not specify a Maximum Time Range or if
you set the Maximum Time Range to 0 (zero), NNMi determines the best setting for each so
the data fits into the Line Graph displayed.
When viewing a Line Graph, the user can temporarily change the Polling Interval in a Line
Graph. After a graph is re-opened, the Polling Interval returns to this default value.
At each Polling Interval, the NNMi management server performs an ad-hoc SNMP query to
obtain the most current data.
Page 293 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring the NNMi User Interface
Attribute
Description
Default
Maximum
Time
Range
(Hours)
The maximum time period in hours in which to retain the Line Graph data point sets. When
the Maximum Time Range number is reached, NNMi discards the oldest data point sets so
that it can display the most recent data for the time range you specify. For example, if you
enter 24 hours, when 24 hours has passed, NNMi removes data starting with the initial data
point set so that it can display data for the most recent 24-hour interval.
Enter a decimal number indicating the maximum number of hours in which to retain the
data.
If you do not specify a Maximum Time Range or if you specify 0 (zero), NNMi determines the
best setting for the Maximum Time Range based on the Polling Interval specified.
If you do not specify a Default Maximum Time Range or set the Default Maximum Time
Range to 0 (zero), and you do not specify a Default Polling Interval, NNMi determines the
best settings for each so the data fits into the Line Graph displayed.
You can override this number for an individual graph. See "Configure SNMP Line Graph
Actions" (on page 888) for more information.
Default
Number
of Lines
The Default Number of Lines determines the initial number of lines that are displayed on
each Line Graph.
Note: If more lines than this initial number are available, the user can choose to display
additional lines while viewing the graph.
You can override this number for an individual graph. See "Configure SNMP Line Graph
Actions" (on page 888) for more information.
Configure Menus
As an NNMi administrator, you configure how menu items are nested beneath the Actions menu. See
"Create Menu Nesting (in the Actions Menu)" (on page 871) for more information.
Configure Menu Items
The Menu Items tab of the User Interface Configuration option enables you to make changes or
additions to the items available in the Actions menu. For example, you can configure Line Graphs (Graph
Action) and additional NNMi Actions (Launch Action) menu items that access in-house tools, Web sites, or
a variety of other resources. See "Configure Menu Item Basic Details" (on page 872) for more information.
Page 294 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
Configuring Trap Forwarding
NNMi enables you to configure SNMP trap forwarding using the Trap Forward Configuration workspace.
This feature is useful when you want to forward traps to a specified destination. For example, you might
want to forward certain kinds of traps to one server and forward another set of traps to a different server so
they can be managed separately.
When configuring SNMP trap forwarding you perform the following tasks:
l
"Configure NNMi Security Settings for SNMPv3 Trap Forwarding" (on page 295)
l
"Configure Trap Forwarding Filters" (on page 297)
l
"Configure Trap Forwarding Destinations" (on page 299)
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
(NNMi Advanced - Global Network Management feature) If you want to forward specific SNMP traps from
your NNMi management server (a Regional Manager) to all Global Managers in your Global Network
management environment, see "Configure Forward to Global Manager Settings for an SNMP Trap Incident
(NNMi Advanced)" (on page 549)
Configure NNMi Security Settings for SNMPv3 Trap Forwarding
Note: If your network environment uses SNMPv2c or SNMPv1 and does not use SNMPv3, skip this task.
If your network environment uses SNMPv3, specify which user-based security model (USM) settings the
NNMi management server uses when NNMi acts as an authoritative entity in the following situations:
l
Forwarding SNMPv3 traps to other devices in your network environment
l
Sending responses to SNMPv3 Inform-Requests
The settings in this form grant permission for NNMi to communicate with the SNMPv3 agent. The SNMPv3
engine identifier and the user-based security settings are required for successful authentication in
SNMPv3 protocol.
To configure the NNMi management server as an authoritative entity for SNMPv3:
1. Prerequisite: When receiving SNMPv3 data, NNMi must decrypt the data received based on the
applicable SNMP Minimum Security Level setting in the Communication Configuration workspace. If
the applicable SNMPv3 Minimum Security Level = No Authentication, No Privacy, NNMi discards all
SNMPv3 traps from the device:
n
"Configure Default SNMP and ICMP Protocol Settings" (on page 67)
n
"Communication Region Form" (on page 80)
n
"Specific Node Settings Form (Communication Settings)" (on page 96)
2. Navigate to the Trap Forward Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Trap Forward Configuration.
3. Navigate to the NNMi SNMPv3 Trap Forwarding Security Settings group.
Page 295 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
4. NNMi displays the ID of the engine assigned to the SNMPv3 agent that NNMi uses when forwarding
or sending data to other SNMPv3 agents. See the attribute value for Engine Id.
5. Provide the USM information that NNMi uses for authentication and privacy when using SNMPv3
protocol for sending traps or responses to Inform-Requests to other devices in your network
environment (see table).
6. Click
Save and Close to save your changes.
SNMPv3 Engine Assigned to NNMi management server
Attribute
Description
Engine
Id
Remote devices must request this SNMPv3 engine ID when sending traps to NNMi. If the
SNMPv3 agent sending data to NNMi does not know the correct engine ID, the trap is
rejected.
SNMPv3 Settings of the NNMi management server's User-Based Security Model (USM)
Attribute
Description
User Name
The SNMPv3 User Name is the text string used for SNMPv3 requests in your network
environment.
Authentication
Protocol
The SNMPv3 authentication protocol. Determines whether authentication is required
and indicates the type of authentication protocol used. NNMi supports the following
protocols:
Authentication
Passphrase
l
HMAC1-MD52-96 authentication protocol
l
HMAC3-SHA4-1 authentication protocol
The SNMPv3 USM authentication passphrase used by the NNMi management server. If
required for authentication, provide the appropriate authentication passphrase for the
authentication protocol.
The length limitations of the authentication passphrase depend on the authentication
protocol.
Privacy
Protocol
Specify the SNMPv3 USM privacy protocol used by the NNMi management server.
Privacy
Passphrase
Specify the SNMPv3 USM privacy passphrase used by the NNMi management server.
This determines whether encryption is required and indicates the type of privacy
protocol used. NNMi supports the DES5-CBC6 Symmetric Encryption Protocol.
If required for privacy, provide the appropriate encryption passphrase for use with the
privacy protocol.
The length limitations of the privacy passphrase depend on the privacy protocol.
1Hash-based Message Authentication Code
2Message-Digest algorithm 5
3Hash-based Message Authentication Code
4Secure Hash Algorithm
5Data Encryption Standard
6Cipher Block Chaining
Page 296 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
Registration Attributes
Attribute
Description
Last Modified
Date and time the Trap Forward Configuration was last modified.
Configure Trap Forwarding Filters
Pre-requisite: Make sure you have used the NNMi nnmincidentcfg.ovpl command line utility to
automatically create or update the incident configurations for the SNMP traps you want to include. See
"Load SNMP Trap Incident Configurations" (on page 425) for more information.
Use the Trap Forward Configuration: Trap Forwarding Filters tab to configure a filter expression to specify
the SNMP trap Object Identifier (OID) pattern you want to use to determine which SNMP traps NNMi
forwards. The traps which pass the filter you specify can then be forwarded to a specified destination using
the Trap Forwarding Destinations tab. See "Configure Trap Forwarding Destinations" (on page 299) for
more information.
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure Trap Forwarding Filters:
1. Navigate to the Trap Forward Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Trap Forward Configuration.
2. Select the Trap Forwarding Filters tab.
3. Do one of the following:
n
To create an SNMP Trap Forwarding Filter configuration, click the
n
To edit an SNMP Trap Forwarding Filter configuration, click the
representing the configuration you want to edit, and continue.
n
To delete an SNMP Trap Forwarding Filters configuration, click the
New icon, and continue.
Open icon in the row
Delete icon.
4. In the "Trap Forwarding Filter Form" (on page 297) provide the required information.
5. Click
Save and Close to save your changes and return to the Trap Forward Configuration form.
The next time that a trap of this type arrives, NNMi uses the filter you specify to determine whether to
forward the trap to a specified destination.
Trap Forwarding Filter Form
Pre-requisite: Make sure you have used the NNMi nnmincidentcfg.ovpl command line utility to
automatically create or update the incident configurations for the SNMP traps you want to include. See
"Load SNMP Trap Incident Configurations" (on page 425) for more information.
The Trap Forwarding Filters Form enables you to specify the SNMP trap Object Identifier (OID) pattern you
want to use to determine which SNMP traps NNMi forwards. The traps which pass the filter you specify can
then be forwarded to a specified destination using the Trap Forwarding Destinations tab. See "Configure
Trap Forwarding Destinations" (on page 299) for more information.
Page 297 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure Trap Forwarding Filters:
1. Navigate to the Trap Forward Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Trap Forward Configuration.
2. Select the Trap Forwarding Filters tab.
3. Do one of the following:
n
To add an SNMP Trap Forwarding Filter configuration, click the
New icon, and continue.
n
To edit an SNMP Trap Forwarding Filter configuration, click the
representing the configuration you want to edit, and continue.
Open icon in the row
n
To delete an SNMP Trap Forwarding Filter configuration, click the
Delete icon.
4. Make your configuration choices (see table).
5. Click
Save and Close to save your changes and return to the Trap Forward Configuration form.
SNMP Trap Forwarding Filters Configuration
Attribute
Description
Filter Name
Enter the name you want to use for this SNMP Trap Forwarding Filter configuration.
Alpha-numeric and special characters (~ ! @ # $ % ^ & * ( ) _+) are allowed. No spaces
are allowed.
"Filter Form"
(on page 298)
Access the Filter Expressions tab to access the Filter form and specify the valid SNMP
Object Identifier (OID) pattern to be used for the SNMP trap filter.
Filter Form
Pre-requisite: Make sure you have used the NNMi nnmincidentcfg.ovpl command line utility to
automatically create or update the incident configurations for the SNMP traps you want to include. See
"Load SNMP Trap Incident Configurations" (on page 425) for more information.
The Filter Form enables you to specify the SNMP trap Object Identifier (OID) pattern you want to use to filter
incoming SNMP traps. The traps which pass the filter you specify can then be forwarded to a specified
destination using the Trap Forwarding Destinations tab. See "Configure Trap Forwarding Destinations" (on
page 299) for more information.
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure a Trap Forwarding Filter:
1. Navigate to the Trap Forwarding Filter form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Trap Forward Configuration.
c. Select the Trap Forwarding Filters tab.
d. Do one of the following:
Page 298 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
o To create a new configuration, click the
New icon.
o To edit an existing configuration, click the
Open icon in the row representing the
configuration you want to edit.
e. On the form that opens, navigate to the Filter Expressions tab.
f. Locate the Filter Expressions table.
g. Do one of the following:
o To add a Trap Forwarding Filter, click the
New icon.
o To edit an existing Trap Forwarding Filter, click the
Open icon in the row representing
the configuration you want to edit.
2. Make your configuration choices (see table).
3. Click
Save and Close to save your changes and return to the Trap Forward Configuration form.
SNMP Trap Forwarding Filter Expression Configuration
Attribute
Description
Trap Object
Identifier
(OID)
Enter the Trap Object Identifier (OID) pattern you want to use for the SNMP trap filter.
Valid values include:
l
The entire SNMP trap OID value. For example: .1.3.6.1.6.5.66.7.1225
l
The SNMP trap OID value that includes a wildcard as a placeholder for the missing
values. For example, to specify only the SNMP trap OID matching prefix:
.1.3.6.1.6.5.66.7.*
Configure Trap Forwarding Destinations
Pre-requisite: Make sure you have used the NNMi nnmincidentcfg.ovpl command line utility to
automatically create or update the incident configurations for the SNMP traps you want to include. See
"Load SNMP Trap Incident Configurations" (on page 425) for more information. You must also create
the Trap Forwarding Filters for the SNMP traps you want to forward. See "Configure Trap Forwarding
Filters" (on page 297) for more information.
The Trap Forwarding Destinations tab enables you to specify the servers to which you want to forward
SNMP traps. Use this tab to also specify the Trap Forwarding Filters to be used for this destination.
(NNMi Advanced) If this NNMi management server is a Regional Manager in your environment, see also
"Configure Forward to Global Manager Settings for an SNMP Trap Incident (NNMi Advanced)" (on page
549).
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure Trap Forwarding Destinations:
1. Navigate to the Trap Forward Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Trap Forward Configuration.
Page 299 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
2. Select the Trap Forwarding Destinations tab.
3. Do one of the following:
n
To create an SNMP Trap Forwarding Destination configuration, click the
continue.
n
To edit an SNMP Trap Forwarding Destination configuration, click the
representing the configuration you want to edit, and continue.
n
To delete an SNMP Trap Forwarding Destination configuration, click the
New icon, and
Open icon in the row
Delete icon.
4. In the "Trap Forwarding Destination Form" (on page 300), provide the required information.
5. Do one of the following:
n
To create an SNMP Trap Forwarding Filter configuration, click the
n
To edit an SNMP Trap Forwarding Filter configuration, click the
representing the configuration you want to edit, and continue.
n
To delete an SNMP Trap Forwarding Filter configuration, click the
New icon, and continue.
Open icon in the row
Delete icon.
6. In the "Destination Filter Form" (on page 302), provide the required information.
7. Click
Save and Close to save your changes and return to the Trap Forward Configuration form.
The next time a trap that passes the Trap Forwarding Filter arrives, NNMi forwards the trap to the specified
Trap Forwarding Destination.
Trap Forwarding Destination Form
Pre-requisite: Make sure you have used the NNMi nnmincidentcfg.ovpl command line utility to
automatically create or update the incident configurations for the SNMP traps you want to include.
See "Load SNMP Trap Incident Configurations" (on page 425) for more information. You must also
create the Trap Forwarding Filters for the SNMP traps you want NNMi to forward. See "Configure
Trap Forwarding Filters" (on page 297) for more information.
The Trap Forwarding Destinations form enables you to specify the servers to which you want NNMi to
forward SNMP traps.
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure a Trap Forwarding Destination:
1. Navigate to the Trap Forward Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Trap Forward Configuration.
2. Select the Trap Forwarding Destinations tab.
3. Do one of the following:
n
To add an SNMP Trap Forwarding Destination configuration, click the
the configuration you want to edit, and continue.
Page 300 of 1087
New icon that precedes
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
n
To edit an SNMP Trap Forwarding Destination configuration, click the
representing the configuration you want to edit, and continue.
n
To delete an SNMP Trap Forwarding Destination configuration, click the
Open icon in the row
Delete icon.
4. Make your configuration choices (see table).
5. Click
Save and Close to save your changes and return to the Trap Forward Configuration form.
SNMP Trap Forwarding Destination Configuration
Attribute
Description
Destination
Name
Enter the name you want to use for this SNMP Trap Forwarding Destination
configuration.
Alpha-numeric and special characters (~ ! @ # $ % ^ & * ( ) _+) are allowed. No spaces
are allowed.
Destination
Address
Enter the IP address for the destination server.
Destination
Port
Enter the UDP port number for the destination server.
Forwarding
Options
(NNMi Advanced) You can use IPv4 or IPv6 addresses.
l
Default - NNMi processes the trap prior to forwarding. Click here for more
information.
NNMi adds two new varbinds to the trap for storing origin address information:
n
Origin IP Address
n
Origin IP Address type
See "Trap Varbinds Provided by NNMi" (on page 302) for more information.
l
SNMPv3 to SNMPv2c Conversion - NNMi converts an incoming SNMPv3 trap to
SNMPv2c. Click here for more information.
When converting SNMPv3 traps to SNMPv2c traps, NNMi does the following:
n
Includes a Context Name varbind - Contains the contextName from the original
SNMPv3 trap.
n
Creates a Community Name - The Context Engine ID and SNMPv3 User Name
of the original SNMPv3 trap are combined as follows:
username@contextEngineID. For example,
ciscoAdmin@8000000b7f3cbec5632b47455e97070c
See "Trap Varbinds Provided by NNMi" (on page 302) for more information.
l
Specify the
Trap
Forwarding
Filters to Use
Original Trap (UNIX only/IPv4 only) - NNMi forwards the trap without any changes
under certain circumstances. Click here for more information.
n
Only forwarded from NNMi management servers on UNIX operating systems.
n
Only forwards traps received-from IPv4 sources and forwarded-to IPv4
destinations.
Use the Trap Forwarding Filters form to specify the Trap Forwarding Filters
configurations to use. These filters determine which traps NNMi forwards to the
destination you specify.
Page 301 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
Attribute
Description
Destination Filter Form
Pre-requisite: Make sure you have used the NNMi nnmincidentcfg.ovpl command line utility to
automatically create or update the incident configurations for the SNMP traps you want to include. See
"Load SNMP Trap Incident Configurations" (on page 425) for more information. You must also create
the Trap Forwarding Filters for the SNMP traps you want to forward. See "Configure Trap Forwarding
Filters" (on page 297) for more information.
The Trap Forwarding Filter Form enables you to specify the Trap Forwarding Filters that you want to apply
for the SNMP traps NNMi forwards to the specified Trap Forwarding Destination.
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure the Trap Forwarding Filters:
1. Navigate to the Trap Forwarding Filter form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Trap Forward Configuration.
c. Select the Trap Forwarding Destinations tab.
d. Do one of the following:
o To create a new configuration, click the
New icon, and continue.
o To edit an existing configuration, select a row, and click the
Open icon in the row
representing the configuration you want to edit, and continue.
e. On the form that opens, navigate to the FIlter Expressions tab.
f. Locate the Filter Expressions table.
g. To create a Filter Expression, click the
New icon.
2. Make your configuration choices (see table).
3. Click
Save and Close to save your changes and return to the Trap Forward Configuration form.
SNMP Trap Forwarding Filter
Attribute
Filter
Description
Click the
Lookup icon, and select
Open from the drop-down menu to view
information about the selected Filter, if any. Select
Quick Find to select the Trap
Forwarding Filter you want to use for the current Trap Forwarding Destination.
Trap Varbinds Provided by NNMi
NNMi provides the following varbinds for use when forwarding SNMP traps.
Note: NNMi does not create these varbinds if the Forwarding Options attribute is set to Original Trap (UNIX
only) when configuring trap forwarding destinations. See "Trap Forwarding Destination Form" (on
page 300) for more information.
Page 302 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Trap Forwarding
SNMP Trap Varbinds Provided by NNMi
Name
oid
Type
Description
Origin IP
address
.1.3.6.1.4.1.11.2.17.2.19.1.1.3
InetAddress
Contains the IP address (v4 / v6) of the
original SNMP notification that generated
the trap.
Origin IP
Address
type
.1.3.6.1.4.1.11.2.17.2.19.1.1.2
InetAddressType
Contains the type of the IP address (v4 /
v6) of the Original IP Address varbind. The
value "1" indicates IPv4 and "2" indicates
IPv6.
Context
Name
.1.3.6.1.4.1.11.2.17.2.19.1.1.1
SnmpAdminString
Contains the contextName present in the
original SNMPv3 notification. This varbind
is present only when NNMi converts an
SNMPv3 notification to an SNMPv2c trap.
See "Trap Forwarding Destination Form"
(on page 300) and "Configure NNMi
Security Settings for SNMPv3 Trap
Forwarding" (on page 295) for more
information.
Page 303 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Configuring Incidents
Incidents are information that NNMi considers important to bring to your attention regarding your network.
See "How NNMi Gathers Incidents" (on page 305) for more information.
NNMi provides a set of incident configurations for the following:
l
Traps generated from an SNMP agent (SNMPv1, SNMPv2c, or SNMPv3)
l
Management incidents that are generated by NNMi
l
Events generated by NNM 6.x or 7.x management stations
See "Incident Configurations Provided by NNMi" (on page 310) for more information about the
configurations provided.
NNMi provides one centralized location, the incident views, where the management events, SNMP traps,
and NNM 6.x or 7.x forwarded events are visible to your team. You control which SNMP traps and NNM 6.x
or 7.x events are considered important enough to show up as incidents. You can also configure how
incidents that are generated by NNMi are displayed. You and your team can easily monitor the incidents
and take appropriate action to preserve the health of your network.
You may choose to modify the incident configurations provided by NNMi or create new incident
configurations. To do so, see the following topics:
l
"Configuring Trap Forwarding" (on page 295)
l
"Configure SNMP Trap Incidents" (on page 432)
l
"Configure Management Events" (on page 724)
l
"Configure Remote NNM 6.x/7.x Events" (on page 579)
l
Using the Incident Configuration form, you can also configure pairwise correlations. See "About
Pairwise Configurations" (on page 344) for more information.
Caution: If you make changes to an incident configuration provided by NNMi, those changes are at risk of
being overwritten in the future. See Author form for important information.
You can also use the Incident Configuration form to define relationships between multiple incidents by
creating deduplication and rate configurations. See "Manage the Number of Incoming Incidents" (on page
338), "Correlate Duplicate Incidents (Deduplication Configuration)" (on page 343), and "Track Incident
Frequency (Rate: Time Period and Count)" (on page 344), for more information.
You can use the Incident Configuration form to control how NNMi handles incoming SNMP traps. See
"Handle Unresolved Incoming Traps" (on page 428) and "Control which Incoming Traps Are Visible in
Incident Views" (on page 427) for more information.
Note: Each time you stop and restart ovjboss, any incidents that have not yet been correlated or persisted
are lost. This means that after a restart of ovjboss, an incoming incident might not be correlated as
expected. For example, after a restart of ovjboss, a duplicate incident might not be correlated under
its original parent incident. Instead, a new parent incident might be generated. See "Stop or Start an
NNMi Process" (on page 45) for more information about starting and stopping the ovjboss process.
Page 304 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Manage Incidents Using Incident Configurations
NNMi enables you to control the incidents that are generated and how they are displayed. To help you
manage your incidents and incident configurations, you want to understand the following:
n
"How NNMi Gathers Incidents" (on page 305)
n
"How NNMi Closes Incidents" (on page 308)
n
"Incident Configurations Provided by NNMi" (on page 310)
When managing your incidents using Incident Configurations, you can perform the following tasks:
n
"Manage the Number of Incoming Incidents" (on page 338)
n
"Track Incident Frequency (Rate: Time Period and Count)" (on page 344)
n
"Configure an Action for an Incident" (on page 410)
n
"Configure Diagnostics for an Incident (NNM iSPI NET)" (on page 417)
How NNMi Gathers Incidents
Incidents are information that NNMi considers important to bring to your attention regarding your network.
NNMi gathers incident information from the sources described in the following table.
Incidents Collected by NNMi
Information
Source
Description
Causal
Engine Management
Events
The NNMi Causal Engine analyzes the health of your network and provides the ongoing
health status reading for each device. The Causal Engine also extensively evaluates
problems and determines the root cause for you, whenever possible, sending incidents
to notify you of problems. Any incident generated from a Causal Engine management
event has an Origin of NNMi in your incident views. See Using the Incident Form for more
information about incident attributes.
SNMP Traps
Traps are unsolicited SNMP notifications that come from your network devices. The NNMi
Causal Engine uses this information as symptoms during its analysis. SNMP traps can
also appear as incidents if configured to do so, using the NNMi incident configuration
feature. See "Configure SNMP Trap Incidents" (on page 432) for more information.
NNM 6.x and
7.x Events
NNMi can display NNM 6.x and 7.x events that are configured to be forwarded to NNMi.
See "The NNMi Causal Engine and Incidents" (on page 306) for an overview of what the NNMi Causal
Engine does with the information collected. See "About the Event Pipeline" (on page 307) for an overview
of the event pipeline path each trap or NNMi event takes before NNMi creates an incident. This
chronological path guarantees that the data is analyzed in chronological order.
Note: The Causal Engine also sends incident information that it generates through the event pipeline to
guarantee the chronological order for determining its root cause incidents.
By default, NNMi includes preconfigured definitions for SNMP traps, NNM 6.x and 7.x events, and the
incidents generated by the NNMi Causal Engine. See Incident Views Provided by NNMi for more
information.
Related Topics
Page 305 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
"Configure SNMP Trap Incidents" (on page 432)
"Configure Management Events" (on page 724)
"Configure Remote NNM 6.x/7.x Events" (on page 579)
"Incident Configurations Provided by NNMi" (on page 310)
"Manage the Number of Incoming Incidents" (on page 338)
The NNMi Causal Engine and Incidents
The Causal Engine extensively evaluates network issues and determines the root cause for you,
whenever possible, sending incidents to notify you of problems.
The NNMi Causal Engine defines root cause in terms of symptoms. To do so, it uses a set of rules to define
relationships for fault and performance (thresholding) symptoms and root causes. Sources of symptom
information include SNMP traps and the monitoring information from the State Poller. See "How NNMi
Gathers Incidents" (on page 305) for more information.
The NNMi Causal Engine communicates through incidents in the following ways:
l
The Causal Engine generates notifications about problems.
l
The Causal Engine closes incidents that are no longer valid (for example, when a "Cold Start" trap is
received a short time after a "Node Down" incident was generated because a device was recently
rebooted).
l
The Causal Engine creates a parent-child relationship between incidents that are all related to one
problem (for example, a "Node Down" incident contains a child "Interface Down" incident for each
neighboring interface of the node).
l
The Causal Engine creates parent-child relationships between incidents that are correlated using the
Custom Correlation configuration. See "Configure Custom Correlations" (on page 353) for more
information.
The Causal Engine uses the following three stages to help determine and display root cause incidents and
their related conclusions.
NNMi Causal Engine Stages
Causal Engine
Stages
Description
Condition
Listener
Collects symptoms from NNMi processes and services.
Hypothesis
engine
Analyzes these symptoms to determine relationships until a root cause is reached.
Blackboard
Based on the information sent by the hypothesis engine, the blackboard updates a
device's status and posts any related incidents.
The NNMi Causal Engine analyzes the health of your network and provides the ongoing health status
reading for each node, interface, IP address, SNMP agent, and connection. See "The NNMi Causal Engine
and Monitoring" (on page 214) for more information.
Page 306 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
About the Event Pipeline
Any incident information that appears in your incident views first travels through the event pipeline. The
event pipeline guarantees that the incident data is analyzed in chronological order.
Note: Not all information that travels through the pipeline results in an incident.
If at any time an incident does not meet the criteria for a stage in the event pipeline, it is ignored and
passed to the next stage in the pipeline. The following table describes the stages contained in the event
pipeline.
NNMi Event Pipeline Stages
Event
PipelineStages
Description
SNMP Trap
and Event
Receiver
Accepts all SNMP traps.
pmd Receiver
Accepts NNM events forwarded from remote NNM 6.X and 7.X management stations.
Incident
Receiver
Accepts all incident information that comes from the NNMi Causal Engine. See "The
NNMi Causal Engine and Incidents" (on page 306)
Note: The incident information that is received includes any Custom Correlation
configurations.
Geo Incident
Receiver
Accepts all incident information that comes from Global or Regional Managers.
Type Enforcer
Determines if a configuration exists for this trap, event, or incident.
If the incident configuration exists, the type enforcer begins to populate the incident
fields according to the configuration. Examples of the incident fields that are populated
include Severity, Origin, Category, and Correlation Nature. If an incident
configuration is disabled or does not exist for the incident, NNMi drops the incident.
Resolver
Determines if the incident's Source Node or Source Object (such as interface or card)
matches an object in the NNMi database. If available, the resolver populates the
incident with the most current Source Node and Source Object attribute values.
Customization
Checks for any of the following incident configurations in the order listed:
l
Suppression
l
Enrichment
l
Dampening
Store Bulk
Collects incidents and stores them.
Notification
Notifies other process and services about a new incident.
Pairwise
Checks for any current pairwise configurations for the incident.
Rate
Checks for any current rate configurations for the incident.
Dedup
Checks for any current deduplication configurations for the incident.
Relate
Performs any additional Causal Engine correlations, including Custom Correlations,
and cancels the incident when applicable.
Page 307 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Event
PipelineStages
Actions
Description
Performs any automatic actions that the NNMi administrator has configured to be run
for one or more incidents. See Using Actions to Perform Tasks for more information.
How NNMi Closes Incidents
NNMi closes incidents under the following circumstances:
l
The incident's configuration is a Pairwise Configuration and both incidents specified in the pair
occurred in the order specified. See "About Pairwise Configurations" (on page 344) for more
information.
l
NNMi determines that the problem that generated the incident is resolved. For example, NNMi closes a
Down incident when it generates a Conclusion that indicates the node or device is available for use,
has returned to a normal state for a specified threshold, or otherwise no longer needs immediate
attention.
See the tables that follow, beginning with Down Incidents and Associated Conclusions for the list of
Conclusions that cause NNMi to set a corresponding Down incident Lifecycle State to Closed.
The name used to identify each Down incident in the following tables is the Name value used for the
Incident Configuration. See"Incident Configurations Provided by NNMi" (on page 310) for the incident
configurations that NNMi provides.
An NNMi administrator can also manually change the incident Lifecycle State to Closed. An operator might
also be able to change the incident Lifecycle State to Closed if the NNMi administrator chooses to make
this Action available.
Note the following:
l
The NNMi Causal Engine does not generate Conclusions during initial discovery.
l
NNMi only Closes incidents for those objects that have one or more outstanding Conclusions as
indicated in the object form's Conclusions tab.
Down Incidents and Conclusion Reasons for Closing Down Incidents
Down Incident
Conclusion Reason for Closing the Down Incident
AddressNotResponding
AddressResponding
BufferOutOfRangeOrMalfunctioning
BufferInRangeAndFunctioning
ConnectionDown
ConnectionUp
ConnectionPartiallyUnresponsive
ConnectionUp
CpuOutOfRangeOrMalfunctioning
CpuInRangeAndFunctioning
CustomPollCritical
CustomPollNormal
CustomPollMajor
CustomPollNormal
CustomPollMinor
CustomPollNormal
CustomPollWarning
CustomPollNormal
Page 308 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Down Incident
Conclusion Reason for Closing the Down Incident
FanOutOfRangeOrMalfunctioning
FanInRangeAndFunctioning
InterfaceDisabled
InterfaceEnabled
InterfaceDown
InterfaceUp
MemoryOutOfRangeOrMalfunctioning
MemoryInRangeAndFunctioning
NodeDown
NodeUp
NodeOrConnectionDown
NodeUp
NonSNMPNodeUnresponsive
NodeUp
PowerSupplyOutOfRangeOrMalfunctioning
PowerSupplyInRangeAndFunctioning
VoltageOutOfRangeOrMalfunctioning
VoltageInRangeAndFunctioning
TemperatureOutOfRangeOrMalfunctioning
TemperatureInRangeAndFunctioning
Down Incidents and Associated Conclusions (NNMi Advanced)
Down Incident
Conclusion
AggregatorDegraded
AggregatorUp
AggregatorDown
AggregatorUp
AggregatorLinkDegraded
AggregatorLinkUp
AggregatorLinkDown
AggregatorLinkUp
RrgMultiplePrimary
RrgOnePrimary
RrgMultipleSecondary
RrgOneSecondary
RrgMultipleSecondary
RrgManyExpectedSecondary
RrgNoPrimary
RrgOnePrimary
RrgNoSecondary
RrgOneSecondary
RrgNoSecondary
RrgManyExpectedSecondary
Down Incidents and Associated Conclusions (HP Network Node Manager iSPI Performance
for Metrics Software)
Down Incident
Conclusion
InterfaceInputDiscardRateHigh
InterfaceInputDiscardRateNominal
InterfaceInputErrorRateHigh
InterfaceInputErrorRateNominal
InterfaceInputUtilizationHigh
InterfaceInputUtilizationNominal
InterfaceInputUtilizationLow
InterfaceInputUtilizationNormal
Page 309 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Down Incident
Conclusion
InterfaceInputUtilizationNone
InterfaceInputUtilizationNominal
InterfaceOutputDiscardRateHigh
InterfaceOutputDiscardRateNominal
InterfaceOutputErrorRateHigh
InterfaceOutputErrorRateNominal
InterfaceOutputUtilizationHigh
InterfaceOutputUtilizationNominal
InterfaceOutputUtilizationLow
InterfaceOutputUtilizationNominal
InterfaceOutputUtilizationNone
InterfaceOutputUtilizationNominal
InterfacePerformanceCritical
InterfacePerformanceClear
InterfacePerformanceWarning
InterfacePerformanceClear
Incident Configurations Provided by NNMi
NNMi provides several incident configurations out-of-the-box. You can review these configurations or
modify these configurations to better meet your needs. For example, you might want to customize the
message that appears with a particular type of incident, including adding information to the message
displayed.
You might also choose to create your own configurations for additional SNMP traps that are important to
you.
These out-of-the-box configurations are organized according to the following categories:
"SNMP Trap Incident Configurations Provided by NNMi" (on page 313)
"Management Event Configurations Provided by NNMi" (on page 327)
"Remote NNM 6.x/7.x Event Configurations Provided by NNMi" (on page 325)
"Incident Pair (Pairwise) Configurations Provided by NNM" (on page 345)
Caution: If you make changes to an incident configuration provided by NNMi, those changes are at risk of
being overwritten in the future. See Author form for important information.
Custom Incident Attributes Provided by NNMi (for Administrators)
NNMi uses custom incident attributes to attach additional information to incidents.
A subset of CIAs are available for any particular incident. Any relevant CIAs are displayed on the Incident
form, in the Custom Attributes tab. There are two categories of possible CIAs:
l
SNMP trap varbinds identified by the Abstract Syntax Notation value (ASN.1). Varbinds are defined in
MIB files that you can load into NNMi. See "Load SNMP Trap Incident Configurations" (on page 425).
l
Custom incident attributes provided by NNMi.
The potential custom incident attributes provided by NNMi are described in the table below.
Custom Incident Attributes Provided by NNMi
Name
Description
cia.address
SNMP agent address.
Page 310 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
cia.eventoid
NNM 6.x/7.x object identifier (oid) for the incident.
cia.incidentDuration
The time measured in milliseconds between when NNMi detected a problem
with one or more network devices to the time the problem was resolved.
Use this CIA when you need to track the total time a particular object in the
network was down or unavailable.
Note: This CIA is used only when NNMi's Causal Engine has analyzed and
Closed the incident. Any time an incident is closed manually (for
example, by the network operator), NNMi does not include
cia.incidentDuration.
cia.reasonClosed
The Conclusion information identifying the reason NNMi changed the
incident's Lifecycle State to Closed. For example, NNMi might include an
Interface Up Conclusion as the reason an Interface Down incident was
closed.
Note: This CIA is used when NNMi's Causal Engine has analyzed and
Closed the incident. Software that is integrated with NNMi might also
provide values for cia.reasonClosed. Any time an incident is closed
manually (for example, by the network operator), NNMi does not
include cia.reasonClosed.
cia.remotemgr
Hostname or IP address of the either of the following:
l
NNM 6.x or 7.x management station that is forwarding the event
l
(NNMi Advanced - Global Network Management feature) NNMi Regional
Manager that is forwarding the event
cia.remotetopoid
Topology identifier (topoid) of the NNM 6.x or 7.x event.
cia.snmpoid
SNMP trap object identifier.
cia.timeIncidentDetected
The timestamp in milliseconds when NNMi first detected the problem
associated with an incident.
Note: This CIA is used only when NNMi's Causal Engine has analyzed and
Closed the incident. Any time an incident is closed manually (for
example, by the network operator), NNMi does not include
cia.timeIncidentDetected.
cia.timeIncidentResolved
The time when NNMi determines the problem associated with the incident is
resolved.
Note: This CIA is used only when NNMi's Causal Engine has analyzed and
Closed the incident. Any time an incident is closed manually (for
example, by the network operator), NNMi does not include
cia.timeIncidentResolved.
(HP Network Node Manager iSPI Performance for Metrics Software) For network performance monitoring,
additional custom incident attributes are provided for your use. Click here for more information.
Custom Incident Attributes Provided for Thresholding (HP Network Node Manager iSPI
Performance for Metrics Software)
Name
Description
cia.thresholdMeasurementTime
The time at which the threshold was reached for a performance
threshold. For example, if the threshold for the Input Error Rate is 6.0,
and the thresholdMeasuredValue is 6.0, the time at which the
thresholdMeasuredValue become equal to 6.0 is stored in this custom
incident attribute. The time appears in ISO 8601 format.
Page 311 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
cia.thresholdParameter
The monitored attribute that is being measured. For example, Input
Utilization. See "Configure Threshold Monitoring for Nodes (HP
Network Node Manager iSPI Performance for Metrics Software)" (on
page 238) and "Configure Threshold Monitoring for Interfaces (HP
Network Node Manager iSPI Performance for Metrics Software)" (on
page 226)for the complete list of possible attributes. This value is
selected when configuring performance thresholds.
cia.thresholdLowerBound
The configured value for the low performance threshold. See
"Configure Threshold Monitoring for Nodes (HP Network Node
Manager iSPI Performance for Metrics Software)" (on page 238) and
"Configure Threshold Monitoring for Interfaces (HP Network Node
Manager iSPI Performance for Metrics Software)" (on page 226)for
more information about how to configure performance thresholds.
cia.thresholdUpperBound
The configured value for the high performance threshold. See
"Configure Threshold Monitoring for Nodes (HP Network Node
Manager iSPI Performance for Metrics Software)" (on page 238) and
"Configure Threshold Monitoring for Interfaces (HP Network Node
Manager iSPI Performance for Metrics Software)" (on page 226) for
more information about how to configure performance thresholds.
cia.thresholdPreviousValue
Results from the previous Performance Polling Interval. For example,
the performance threshold results for the Input Error Rate might
change from Nominal to High, based on a change in the
thresholdMeasuredValue. See Interface Form for a complete list of
possible values.
cia.thresholdCurrentValue
Results from the most recent Performance Polling Interval. For
example, High. See Interface Form for a complete list of possible
values.
cia.thresholdMeasuredValue
The most recent measurement for the performance threshold. The HP
Network Node Manager iSPI Performance for Metrics Software
software monitors this measurement for threshold violations. This
measurement is the average of all measurements taken during the last
polling interval (determined by the NNMi State Poller).
cia.thresholdMeasurementTime
The time at which the threshold was reached for a performance
threshold. For example, if the threshold for the Input Error Rate is 6.0,
and the thresholdMeasuredValue is 6.0, the time at which the
thresholdMeasuredValue become equal to 6.0 is stored in this custom
incident attribute. The time appears in ISO 8601 format.
These CIAs are used in a variety of ways:
l
In SNMP trap configurations. See "Configure SNMP Trap Incidents" (on page 432).
l
In remote NNM 6.x/7.x events. See "Configure Remote NNM 6.x/7.x Events" (on page 579).
l
In management events. See "Configure Management Events" (on page 724).
l
In automatic actions. See "Configure an Action for an Incident" (on page 410).
Page 312 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
l
In correlation configurations. See "Manage the Number of Incoming Incidents" (on page 338).
l
In Launch Action definitions (access through the Actions menu). See "Control the Actions Menu" (on
page 870).
SNMP Trap Incident Configurations Provided by NNMi
Caution: If the Author value is HP Network Node Manager, any changes are at risk of being overwritten in
the future. See Author form for important information.
NNMi provides the SNMP trap incident configurations described in the following table.
You might also choose to create your own configurations for additional SNMP traps that are important to
you.
SNMP Trap Configurations Provided by NNMi
Deduplication Rate
Configuration Configuration
Incident Configuration Name
Description
BGPBackward Transition
Generated when the BGP Finite State
Machine moves from a higher numbered
state to a lower numbered state.
Name CIA
BGPEstablished
Generated when the BGP Finite State
Machine enters the ESTABLISHED state.
Name CIA
CempMemBufferNotify
Signifies that a cempMemBufferPeak object
has been updated in the buffer pool.
Name
CiscoChassisAlarmOff
Signifies that the agent entity has detected
the chassisTempAlarm, chassisMinorAlarm,
or chassisMajorAlarm object in this MIB has
transitioned to the off(1) state.
Name CIA
CiscoChassisAlarmOn
Signifies that the agent entity has detected
the chassisTempAlarm, chassisMinorAlarm,
or chassisMajorAlarm object in this MIB has
transitioned to the on(2) state.
Name CIA
CiscoChassisChangeNotification
Agent detects any hot-swap component
change or changes in the chassis.
Name CIA
CiscoColdStart
Occurs when a Cisco Agent is powered up.
CiscoDemand NeighborLayer2Change
Sent to the manager whenever the D-channel
of an interface changes state.
CiscoEnvMonFanNotification
Indicates at least one of the fans in the fan
array has failed.
CiscoEnvMonFanStatusChange Notification
Indicates a state change for a device being
monitored by ciscoEnvMonFanState.
CiscoEnvMonRedundantSupplyNotifcation
Indicates the redundant power supply failed.
CiscoEnvMonSuppStatusChangeNotification
Indicates a change in the state of a device
being monitored by
Page 313 of 1087
5 within a
time period of
5 minutes
Name CIA
IF index
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Deduplication Rate
Configuration Configurat
Description
ciscoEnvMonSupplyState.
CiscoEnvMonTemperatureNotification
Indicates the temperature measured at a
given testpoint is outside the normal range for
the testpoint, For example, it is at the warning,
critical, or shutdown stage.
CiscoEnvMonTempStatusChangeNotification
Indicates a change in the state of a device
being monitored by
ciscoEnvMonTemperatureState.
CiscoEnvMonVoltageNotification
Indicates the voltage measured at a given
testpoint is outside the normal range for the
testpoint. For example, it is at the warning,
critical, or shutdown stage.
CiscoEnvMonVoltStatusChangeNotification
Indicates a change in the state of a device
being monitored by
ciscoEnvMonVoltageState.
CiscoFRUInserted
Indicates a Field Replaceable Unit (FRU)
was inserted into the source node.
CiscoFRURemoved
Indicates a Field Replaceable Unit (FRU)
was removed from the source node.
CiscoLinkDown
Occurs when the Cisco agent detects an
interface has gone down.
Name CIA
Occurs when the Cisco agent detects an
interface has come back up.
Name CIA
CiscoModuleDown
Signifies that the SNMP Agent has detected
that the card has gone down.
Name CIA
Module Index
CiscoModuleStatusChange
Indicates the Operational State of the card
has changed.
CiscoModuleUp
Signifies that the SNMP Agent has detected
that the card has come back up.
CiscoRFProgressionNotif
Notification sent by the active Card (for
example Card Active), whenever its
Redundancy Framework (RF) state changes
or the RF state of the second card in the Card
Redundancy Group changes.
CiscoRFSwatcNotif
Sent by the newly Active Card (for example
Card Active). Indicates that a card state has
been switched to a different state.
CiscoUnrecognizedFRU
Indicates the Field Replaceable Unit (FRU)
has a product identification that is not
recognized.
CiscoLinkUp
IF index
IF index
Name CIA
Module Index
Page 314 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Deduplication Rate
Configuration Configuration
Incident Configuration Name
Description
CiscoVlanPortStatusChange
Generated by a device when the value of
vlanTrunkPortDynamicStatus object has
been changed.
CiscoWarmStart
Occurs when an Cisco agent is reconfigured.
HSRPStateChange
Sent when an HSRP interface transitions to
or from an Active or Standby state in a
particular HSRP Group.
Name CIA
IetfVRRPStateChange
Sent when a standard VRRP interface
transitions to or from a Master State in a
particular VRRP Group. This trap is used by
the standard VRRP protocol. It corresponds
to the vrrpTrapNewMaster trap name.
Name CIA
OSPFIfStateChange
Signifies that there has been a change in the
state of a nonvirtual OSPF interface.
Name CIA
OSPFNbrStateChange
Signifies that there has been a change in the
state of a nonvirtual OSPF neighbor.
Name CIA
OSPFVirtIfStateChange
Signifies that there has been a change in the
state of an OSPF virtual interface.
Name CIA
RMONFallingAlarm
Sent when an RMON device falls below a
preconfigured threshold.
Name CIA
RMON Alarm
Variable
Rc2kTemperature
Signifies the SNMPv2c entity acting in an
agent role, has detected the chassis is
overheating.
RcAggLinkDown
Signifies the operational state of the MultiLink Trunk (MLT) Aggregator changed from
Up to Down.
RcAggLinkUp
Signifies the operational state of the MultiLink Trunk (MLT) Aggregator changed from
Down to Up.
RcChasFanDown
Signifies the SNMPv2c entity, acting in an
agent role, has detected that the
rcChasFanOperStatus object for one of its
power supply units is about to transition to the
Down state.
RcChasFanUp
Signifies the SNMPv2c entity, acting in an
agent role, has detected that the
rcChasFanOperStatus object for one of its
power supply units is about to transition to the
Up state.
Page 315 of 1087
Name CIA
5 within a
time period of
5 minutes
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Deduplication Rate
Configuration Configurat
Incident Configuration Name
Description
RcChasPowerSupplyDown
Signifies the rcChasPowerSupplyOperStatus
object for one of its power supply units is
about to transition to the Down state.
RcChasPowerSupplyUp
Signifies the SNMPv2c entity, acting in an
agent role, has detected that the
rcChasPowerSupplyOperStatus object for
one of its power supply units is about to
transition to the Up state.
Rcn2kTemperature
Signifies that the SNMPv2c entity, acting in
an agent role, has detected the chassis is
overheating.
RcnAggLinkDown
Signifies the operational state of the MultiLink Trunk (MLT) Aggregator Link changed
from Up to Down.
RcnAggLinkUp
Signifies the operational state of the MultiLink Trunk (MLT) Aggregator Interface has
changed from Down to Up.
RcnChasFanDown
Signifies the SNMPv2c entity, acting in an
agent role, has detected that the
rcChasFanOperStatus object for one of its
power supply units is about to transition into
the Down state.
RcnChasFanUp
Signifies the SNMPv2c entity, acting in an
agent role, has detected that the
rcChasFanOperStatus object for one of its
power supply units is about to transition into
the Up state.
RcnPowerSupplyDown
Signifies the SNMPv2c entity, acting in an
agent role, has detected that the
rcChasPowerSupplyOperStatus object for
one of its power supply units is about to
transition into the Up state.
RcnPowerSupplyUp
Signifies the SNMPv2c entity, acting in an
agent role, has detected that the
rcChasPowerSupplyOperStatus object for
one of its power supply units is about to
transition into the Up state.
RcnSmltIsLinkDown
Signifies the rcChasPowerSupplyOperStatus
object for one of its power supply units is
about to transition into the Down state.
RcnSmltIsLinkUp
Signifies the rcChasPowerSupplyOperStatus
object for one of its power supply units is
about to transition into the Up state.
Page 316 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Deduplication Rate
Configuration Configuration
Incident Configuration Name
Description
RcSmltIsLinkDown
Signifies the operational state of the Split
Multi-Link Trunk (SMLT) Aggregator Link is
transitioning from Up to Down.
RcSmltIsLinkUp
Signifies the operational state of the Split
Multi-Link Trunk (SMLT) Aggregator Link is
transitioning from Down to Up.
RcVrrpStateChange
Sent when a Rapid City (RC) Nortel interface
transitions to or from a Master state in a
particular VRRP Group. This trap is used by
the Rapid City (RC) Nortel propriety VRRP
protocol. It corresponds to the
rcVrrpTrapNewMaster trap name.
RMONFallingAlarm
Sent when an RMON device falls below a
preconfigured threshold.
RMONRiseAlarm
Sent when an RMON device exceeds a
preconfigured threshold.
SNMPColdStart
Signifies that the sending protocol entity is
reinitializing itself such that the agent's
configuration or the protocol entity
implementation may be altered.
Name CIA
SNMPLinkDown
Signifies that the sending protocol entity
recognizes a failure in one of the
communication links represented in the
agent's configuration.
Name CIA
Signifies that the sending protocol entity
recognizes that one of the communication
links represented in the agent's configuration
has come up.
Name CIA
SNMPWarmStart
Signifies that the sending protocol entity is
reinitializing itself such that neither the agent
configuration nor the protocol entity
implementation is altered.
Name CIA
STPNewRoot
Indicates that the sending agent has become
the new root of the Spanning Tree.
Name CIA
STPTopologyChange
Sent by a bridge when any of its configured
ports transitions from the Learning state to the
Forwarding state, or from the Forwarding
state to the Blocking state.
Name CIA
SNMPLinkUp
IF index
IF index
NNMi Advanced. SNMP Trap Incident Configurations for HP Route Analytics Management Software
(RAMS)
Page 317 of 1087
5 within a
time period of
5 minutes
5 within a
time period of
5 minutes
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
RexAdjStateDown
Signifies the adjacency went down.
RexAdjStateFlap
Signifies the adjacency's flap count
(rexEventCount) in the duration
given by rexCountDuration has
become greater than or equal to
rexEventThreshold.
Deduplication Rate
Configuration Configuration
Both adjacency up and adjacency
down count as flaps. For example:
An adjacency going down and
coming up increments the flap count
by two.
RexAdjStateUp
Signifies the adjacency came up.
RexASPathChange
Signifies the AS path to a route has
changed.
RexBgpRedundChange
Signifies a change in the number of
next hops available for reaching a
prefix
RexBgpVpnReachByCustGain
Signifies the routes in the Customer
announced by PE that are up and
not baselined as compared to the
threshold value. The deviation is
represented as either of the
following:
RexBgpVpnReachByCustLoss
RexBgpVpnReachByRtGain
l
The number of routes in the
Customer that are up and not
baselined
l
The percentage of participating
routes in the Customer that are
up and not baselined
Signifies the routes in the Customer
announced by PE that are down
and not baselined as compared to
the threshold value. The deviation is
represented as either of the
following:
l
The number of routes in the
Customer that are down and not
baselined
l
The percentage of participating
routes in the Customer that are
down and not baselined
Signifies the routes in the Route
Target announced by PE that are up
Page 318 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
and not baselined as compared to
the threshold value. The deviation is
represented as either of the
following:
RexBgpVpnReachByRtLoss
l
The number of routes in the
Route Target that are up and not
baselined
l
The percentage of participating
routes in the Route Target that
are up and not baselined
Signifies the routes in the Route
Target announced by PE that are
down and not baselined as
compared to the threshold value.
The deviation is represented as
either of the following:
l
The number of routes in the
Route Target that are down and
not baselined
l
The percentage of participating
routes in the Route Target that
are down and not baselined
RexPathChange
Indicates the a path attributes such
as metric, number of hops,
intermediate hops from a source
router to a IP prefix or NSAP
address have changed.
RexPeeringStateDown
Indicates a peering between a
router and RAMS has gone down
RexPeeringStateFlap
Indicates a peering between a
router and RAMS has gone down.
RexPeeringStateUp
Indicates a peering between a
router and RAMS has come up.
RexPrefixDrought
Signifies a particular BGP Peer Rib
has decreased significantly from the
Baseline Size as a percentage of
the baseline
RexPrefixFlood
Signifies a particular BGP Peer Rib
has increased significantly from the
Baseline Size as a percentage of
the baseline.
RexPrefixStateDown
Indicates the
prefix(rexDstPrfx,rexDstMask)
announced by
Page 319 of 1087
Deduplication Rate
Configuration Configuration
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
Deduplication Rate
Configuration Configuration
Router(rexSrcRtrSysID, rexSrcRtrIP,
rexSrcRtrName) has gone down.
RexPrefixStateFlap
Indicates the prefix
(rexDstPrfx,rexDstMask) flap count
(rexEventCount) in the duration
given by rexCountDuration
becomes greater than or equal to
rexEventThreshold.
Both prefix up and prefix down
count as flaps. For example: A prefix
going down and coming up
increments the flap count by two.
RexPrefixStateUp
Indicates the
prefix(rexDstPrfx,rexDstMask)
announced by
Router(rexSrcRtrSysID, rexSrcRtrIP,
rexSrcRtrName) has come up.
RexRtrConnected
Indicates the first adjacency of a
router becomes full duplex. This
means the neighbor sends an LSA
and the previously isolated router
sends an LSA across that
adjacency.
RexRtrIsolated
Signifies a router has become
isolated from the rest of the topology
as all of its duplex connections it
has to other routers which are not
overloaded with respect to a
particular routing protocol have
gone down.
RexRtrStateFlap
Signifies the router's flap count
(rexEventCount) in the duration
given by rexCountDuration has
become greater than or equal to
rexEventThreshold. Both router
isolation and router connection
count as flaps. For example: A
router getting isolated and then
connected increments the flap count
by two.
RexTest
This trap is sent for test purposes
Page 320 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
RexVpnPEParticipationByCustGain
Signifies the Provider Edges (PEs)
participating in the Customer that
are up and not baselined as
compared to the threshold value.
The deviation is represented as
either of the following:
RexVpnPEParticipationByCustLoss
RexBgpVpnReachByRtGain
RexVpnPEParticipationByRtLoss
Page 321 of 1087
l
The number of PEs that are up
and not baselined
l
The percentage of participating
PEs that are up and not
baselined
Signifies the Provider Edges (PEs)
participating in the Customer that
are down and not baselined as
compared to the threshold value.
The deviation is represented as
either of the following:
l
The number of PEs that are
down and not baselined
l
The percentage of participating
PEs that are down and not
baselined
Signifies the routes in the Route
Target announced by PE that are up
and not baselined as compared to
the threshold value. The deviation is
represented as either of the
following:
l
The number of routes in the
Route Target that are up and not
baselined
l
The percentage of participating
routes in the Route Target that
are up and not baselined
Signifies the PEs participating in the
Route Target (RT) that are down
and not baselined as compared to
the threshold value. The deviation is
represented as either of the
following:
l
The number of PEs that are
down and not baselined
l
The percentage of participating
PEs that are down and not
baselined
Deduplication Rate
Configuration Configuration
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
RexVpnReachByCustPEGain
Signifies the routes in the Customer
announced by PE that are up and
not baselined as compared to the
threshold value. The deviation is
represented as either of the
following:
RexVpnReachByCustPELoss
l
The number of routes in the
Customer that are up and not
baselined
l
The percentage of participating
routes in the Customer that are
up and not baselined
Deduplication Rate
Configuration Configuration
Signifies the routes in the Customer
announced by PE that are down
and not baselined as compared to
the threshold value. The deviation is
represented as either of the
following:
l
The number of routes in the
Customer that are down and not
baselined
l
The percentage of participating
routes in the Customer that are
down and not baselined
RexVpnReachByCustPrefixDown
Signifies that the prefix has become
unreachable in Customer.
RexVpnReachByCustPrefixUp
Signifies that the prefix has become
reachable in Customer.
RexVpnReachByRtPEGain
Signifies the routes in the Route
Target announced by PE that are up
and not baselined as compared to
the threshold value. The deviation is
represented as either of the
following:
l
The number of routes in the
Route Target that are up and not
baselined
l
The percentage of participating
routes in the Route Target that
are up and not baselined
Page 322 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
RexVpnReachByRtPELoss
Signifies the routes in the Route
Target announced by PE that are
down and not baselined as
compared to the threshold value.
The deviation is represented as
either of the following:
l
The number of routes in the
Route Target that are down and
not baselined
l
The percentage of participating
routes in the Route Target that
are down and not baselined
RexVpnReachByRtPrefixDown
Signifies the prefix has become
unreachable in RT.
RexVpnReachByRtPrefixUp
Signifies that the prefix has become
reachable in RT.
RexVpnSiteExpectedAnncdPfxLoss
Signifies that there is a decrease in
the number of prefixes announced
by the Vpn/Site pair.
RexVpnSiteExpectedRcvdPfxLoss
Signifies that there is a decrease in
the number of prefixes received by
the Vpn/Site pair.
RexVpnSitePrefixStateDown
Signifies the
prefix(rexDstPrfx,rexDstMask)
announced by
Router(rexSrcRtrSysID, rexSrcRtrIP,
rexSrcRtrName) in
VPN(rexVpnName) and
site(rexSiteName), has gone down.
RexVpnSitePrefixStateFlap
Signifies the prefix
(rexDstPrfx,rexDstMask) flap count
(rexEventCount) in the duration
given by rexCountDuration
becomes greater than or equal to
rexEventThreshold.
The prefix is announced by Router
(rexSrcRtrSysID, rexSrcRtrIP,
rexSrcRtrName) in VPN
(rexVpnName) and site
(rexSiteName).
Both prefix up and prefix down
count as flaps. For example: A prefix
going down and coming up
increments the flap count by two.
Page 323 of 1087
Deduplication Rate
Configuration Configuration
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
RexVpnSitePrefixStateUp
Signifies the prefix
(rexDstPrfx,rexDstMask) has come
up.
Deduplication Rate
Configuration Configuration
The prefix is announced by Router
(rexSrcRtrSysID, rexSrcRtrIP,
rexSrcRtrName) in VPN
(rexVpnName) and site
(rexSiteName).
RexVpnSiteUnexpectedAnncdPfxGain
Signifies there is an increase in the
number of prefixes announced by
the Vpn/Site pair.
RexVpnSiteUnexpectedRcvdPfxGain
Signifies there is an increase in the
number of prefixes received by the
Vpn/Site pair.
TrafficHighLinkUtilization
Indicates the traffic volume has
exceeded a specified threshold on a
link. Specify the threshold as an
absolute number in kilobytes per
second or in terms of percentage of
link capacity.
TrafficLinkCoSUtilization
Indicates the traffic volume has
exceeded a specified threshold for a
CoS queue on a link. Specify the
threshold as an absolute number in
kilobytes per second or in terms of a
percentage of link capacity.
TrafficLowLinkUtilization
Indicates the traffic volume has
fallen below a specified threshold
on a link. Specify the threshold as
an absolute number in kilobytes per
second or in terms of percentage of
link capacity.
TrafficQuantityAlert
A generic trap for all non-link related
traffic alerts. Specify the threshold
as an absolute number in kilobytes
per second or in terms of
percentage of link capacity.
To see or modify these SNMP trap incident configurations:
1. Navigate to the Incident Configuration view.
a. In the Workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the SNMP Trap Configuration tab.
Page 324 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
3. Click the
Open icon in the row representing the configuration you want to see or edit.
4. When you are finished, click
Save and Close.
Remote NNM 6.x/7.x Event Configurations Provided by NNMi
Caution: If the Author value is HP Network Node Manager, any changes are at risk of being overwritten in
the future. See Author form for important information.
NNMi provides the remote NNM 6.x or 7.x incident configurations described in the following table.
Remote NNMi Out-of-the-Box Incident Configurations
Incident Configuration Name
Description
OvStationNormal
Generated when the status of an NNM
6.x or 7.x management station changes
to normal/up.
OvStationCritial
Generated when the status of an NNM
6.x or 7.x management station changes
to down/critical.
OvNodeWarning
Generated when NNMi detects the
status of a node has become up (some
or all interfaces in the node are up).
OVNodeMajor
Generated when NNMi detects the
status of a node has become up (some
or all interfaces in the node are up).
OvNodeMarginal
Generated when NNMi detects the
status of a node has become up (some
or all interfaces in the node are up).
OvNodeUp
Generated when NNMi detects the
status of a node has become up (some
or all interfaces in the node are up).
OvNodeDown
Generated when NNMi detects the
status of a node has become down (all
interfaces in the node are down).
OvIfUp
Generated when NNMi detects the
status of an interface has come up,
normally by responding to an ICMP
Echo (ping) request.
OvIfDown
Generated when NNMi detects the
status of an interface has come up,
normally by responding to an ICMP
(ping) request.
OvMessage
Generated by a user to display an event
message in the event browser.
OvIfIntermittent
Generated when NNMi detects the
status of an interface has gone down
and up multiple times.
Page 325 of 1087
Deduplication Rate
Configuration Configuration
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
OvApaAddressUp
Generated by the NNMi Causal Engine
when it detects that the address is
responding to polls.
OvApaIfUp
Generated by the NNMi Causal Engine
when it detects that the interface is
responding to polls.
OvApaNodeUp
Indicates a node's status went from
Down to Up.
OvApaConnUp
Indicates a connection's status went
from Down to Up.
OvApaAggPortUp
Indicates the OperStatus for the logical
aggregate port connection is Up.
OvApaAggPortDown
Indicates the OperStatus for the logical
aggregate port connection is Down.
OvApaAggPortDegraded
Indicates the OperStatus for one of the
physical port connections in the
aggregate connection is Down
OvApaAggPortConnUp
Indicates that an aggregate port
connection between two nodes is
responding to polls and no interfaces
are down on either side of the
connection.
OvApaAggPortConnDown
Indicates an aggregate port connection
between two nodes is not responding to
polls and all interfaces may be down on
both sides of the connection.
OvApaAddressDown
Indicates a node's address status went
from Up to Down.
OvApaIfDown
Iindicates a node's interface status went
from Up to Down.
OvApaNodeDown
Indicates a node's status went from Up
to Down.
OvApaConnDown
Indicates a connection's status went
from Up to Down.
OvAPaIfIntermittent
Indicates an interface's status has gone
Down and Upmultiple times.
OvApaAddressIntermittent
Indicates a node's address status has
gone Down and Up multiple times.
OvApaConnIntermittent
Indicates a network's connection status
has gone Down and Up multiple times.
Deduplication Rate
Configuration Configuration
Page 326 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
OvApaNodeIntermittent
Indicates a node's status has gone
Down and Up multiple times.
OvApaNodeSNMPNotResponding
Indicates an SNMP agent is not
responding to queries.
OvApaAggPortNotDegraded
Indicates all of the physical port
connections in the aggregate
connection are Up.
OvApaIfRemoved
Indicates an interface has been
removed.
OvApaBoardUp
Indicates a node's board status has
gone from Down to Up.
OvApaBoardDown
Indicates a node's board status has
gone from Up to Down.
OvApaBoardRemoved
Indicates a node's board has been
removed.
Deduplication Rate
Configuration Configuration
To see or modify these Remote NNM 6.x and 7.x trap incident configurations:
1. Navigate to the Incident Configuration view.
a. In the Workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the Remote NNM 6.x and 7.x Events tab.
3. Click the
Open icon in the row representing the configuration you want to see or edit.
4. When you are finished, click
Save and Close.
Management Event Configurations Provided by NNMi
Caution: If the Author value is HP Network Node Manager, any changes are at risk of being overwritten in
the future. See Author form for important information.
Deduplication is not configured for out-of-the-box management events. See "Correlate Duplicate Incidents
(Deduplication Configuration)" (on page 343) for information about how to configure deduplication.
NNMi provides the incident configurations for management events. Click here for more information.
To see or modify these management event incident configurations:
1. Navigate to the Incident Configuration view.
a. In the workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the Management Event Configuration tab.
3. Select the configuration you want to see or modify.
Page 327 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
4. Click the
Open to see or change the configuration.
5. When you are finished, click
Save and Close.
Management Event Configurations Provided by NNMi
Incident Configuration Name
Description
Rate
Configuration
AddressNotResponding
Indicate an address is not responding to
ICMP.
5 events in 5
minutes
Reasons an address might not respond
include:
l
Its node is down
l
A device, such as a router, has been misconfigured so that some addresses
cannot be reached
AggregatorDegraded
Indicates one or more (but not all) physical
interfaces that are part of the Aggregator
Interface are not operational.
AggregatorDown
Indicates the operational status of the
Aggregator Interface is down (if monitored),
or all of the corresponding physical
interfaces are Down.
AggregatorLinkDegraded
Indicates any Aggregator Interface is
operationally down on either node, when
there is a connection between two
Aggregator Interfaces.
AggregatorLinkDown
Indicates the Aggregator Interface on either
side of an Aggregator Link connection is
down.
BufferOutOfRangeOrMalfunctioning
Indicates the buffer pool is exhausted or
cannot meet demand.
CardDisabled
Indicates that the card has been disabled by
the device administrator.
CardDown
Indicates the card is not responding to polls.
CardRemoved
Indicates the card was removed from a
device.
CardInserted
Indicates a card was inserted into a device.
CardUndeterminedState
Indicates the card reported a non-normal
state for some unspecified reason.
ConnectionDown
Indicate that both (or all) ends of a
connection are not responding to SNMP
queries.
ConnectionPartiallyUnresponsive
Indicates that a connection is partially
5 events in 5
minutes
Page 328 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
Rate
Configuration
unresponsive. Reasons for this include that
an undiscovered device in the connection is
down.
CpuOutOfRangeOrMalfunctioning
Indicates any of 5 second, 1 minute, or 5
minute utilization averages is too high.
CrgFailover
Indicates the role of a primary card (for
example, Card Active) has moved from one
card to the other in a Card Redundancy
Group. The Card Redundancy Group is
routing packets properly.
CrgMultiplePrimary
Indicates NNMI has identified multiple
primary cards (for example, Card Active ) in
the Card Redundancy Group. This typically
indicates the communication between the
cards in the group is malfunctioning.
CrgNoPrimary
Indicates NNMi is unable to identify a
primary card (for example, Card Active) in
the Card Redundancy Group. This typically
indicates one of the following:
CrgNoSecondary
l
One card, or both cards, are down
l
NNMi has identified only secondary
cards (for example Standby cards) in the
group
l
Communication between cards in the
group is malfunctioning.
Indicates NNMi cannot identify a secondard
card (for example Card Standby) in the Card
Redundancy Group. This typically indicates
the following:
l
One of the two cards in the group is
down.
l
NNMi has identified the other card as
primary (for example, Card Active).
l
The Card Redundancy Group is
functioning properly
CustomPollCritical
Indicates that a Polling Instance associated
with the Custom Poller Collection is in a
Critical State.
CustomPollMajor
Indicates that a Polling Instance associated
with the Custom Poller Collection is in a
Major State.
CustomPollMinor
Indicates that a Polling Instance associated
with the Custom Poller Collection is in a
Page 329 of 1087
3 events in 30
minutes
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Rate
Configuration
Description
Minor State.
CustomPollWarning
Indicates that a Polling Instance associated
with the Custom Poller Collection is in a
Warning State.
DuplicateCorrelation
Provided as a template for configuring
deduplication for an incident to specify which
attribute values NNMi must match to verify
that an incident is a duplicate.
FanOutOfRangeOrMalfunctioning
Indicates the specified fan is not operating
correctly.
ForwardIncidentRateExceeded
(NNMi Advanced) Indicates that the volume
of messages entering a Regional Manager's
Global Network Management message
queue has exceeded the configured rate
limits.
ImportantNodeorConnectionDown
Indicates a node is not responding to an
ICMP or SNMP query. It also indicates that
only one neighbor is down so that the NNMi
Causal Engine cannot determine whether
the node or the connection is down.
ImportantNodeUnmanageable
Indicates a nodes is not responding to an
SNMP query.
InterfaceDisabled
Indicates the interface has been explicitly
disabled by the device administrator.
5 events in 5
minutes
InterfaceDown
Indicates that the interface is not responding
to polls.
5 events in 5
minutes
IslandGroupDown
Indicates all nodes in a group of Layer 2
connected nodes do not respond to
monitoring polls (for example, ICMP or
SNMP).
These groups are automatically discovered
and contain all of the nodes that can be
connected through NNMi topology. Typically,
these are groups on one side of a WAN
(wide area network) connection.
LicenseExpired
Indicates that the expiration date has passed
for an instant-on or temporary NNMi license
key. See "Extend a Licensed Capacity" (on
page 1013).
Page 330 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
LicenseMismatch
Indicates that the licensed capacity for NNMi
does not match the licensed capacity for one
of the following products in your network
environment:
l
An NNMi Integration Enablement
l
HP Network Node Manager iSPI Network
Engineering Toolset Software (NNM iSPI
NET)
l
HP Network Node Manager iSPI
Performance for Metrics Software
l
HP Network Node Manager iSPI
Performance for Traffic Software
Note: The licensed capacity count is
cumulative for each licensed product
(across all installed license keys for
that licensed product).
See "Extend a Licensed Capacity" (on page
1013).
LicenseNodeCountExceeded
Indicates that the number of discovered
nodes exceeds the licensed capacity for
managed node count. See "Extend a
Licensed Capacity" (on page 1013).
MemoryOutOfRangeOrMalfunctioning
Indicates the Source Node's memory pool is
exhausted or cannot meet the demand for
use.
MemoryQueueIncidentRateExceeded
(NNMi Advanced) Indicates the rate at which
NNMi forwards incidents to the Global
Manager has exceeded the maximum
allowed. NNMi no longer forwards incidents
generated from SNMP traps and NNM 6.x/7.x
Remote Events.
MessageQueueSizeExceeded
Indicates one of the queues connecting the
stages for the Event Pipeline is above the
configured limits. NNMi determines queue
size limits based on memory size.
ModifiedConnectionDown
Indicates a connection has been
disconnected, moved, or both and is not
responding to SNMP queries.
NnmClusterFailover
Indicates the NNMi cluster detected a failure
of the active server. NNMi services were
started on the standby server.
NnmClusterLostStandby
Indicates the NNMi cluster active server lost
its communication to the standby server.
Page 331 of 1087
Rate
Configuration
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Rate
Configuration
Incident Configuration Name
Description
NnmClusterStartUp
Indicates the NNMi cluster was started in a
state where no active server was already
present. Therefore the server was started in
the active state.
NnmClusterTransfer
Indicates the system administrator moved the
active state from one server to another. The
NNMi services will then start on the new
active server.
NodeDown
Indicates that the NNMi Causal Engine has
determined the node is down based on the
following analysis:
5 events in 5
minutes
100% of the addresses assigned to this node
are unreachable
The SNMP agent installed on this machine is
not responding
NNMi is communicating with at least two of
the neighboring devices. And at least two
neighboring devices report problems with
connectivity to this node.
NodeOrConnectionDown
Indicate a node is not responding to an ICMP
or SNMP query. It also indicates that only
one neighbor is down so that the NNMi
Causal Engine cannot determine whether
the node or the connection is down.
Node Up
Indicates the node is up based on the
following analysis:
l
All of the addresses assigned to this
node are reachable.
l
The SNMP agent installed on this node is
responding.
l
At least two of the neighboring devices
can be reached and are not reporting
problems with connectivity to this node.
NonSNMPNodeUnresponsive
Indicates that a Non-SNMP node is
unresponsive. Reasons for this include: 1)
The node is down, or 2) An undiscovered
device in the path between the node and the
NNMi management server is down.
PowerSupplyOutOfRangeOrMalfunctioning
Indicates a power supply for the Source
Node is not operating correctly.
RateCorrelation
Provided as a template to measure the
number of incoming incidents within a
defined time period.
Page 332 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
RrgDegraded
Note: This incident occurs only in Router
Redundancy Groups using the HSRP
protocol and larger than two
members.
Indicates the following:
l
The Router Redundancy Group has a
primary and secondary device.
l
The remaining devices in the group are
not in an expected protocol-specific state.
For example, in HSRP other devices may
be expected to be in the "Listen" state.
Typically, the protocol-specific
communication between routers is
malfunctioning. However, the group is
routing packets properly.
RrgFailover
Indicates a primary role (for example, HSRP
Active or VRRP Master) moved from one
device to another in a Router Redundancy
Group.
Reasons for this incident include one or
more of the following:
l
A router or interface in the Router
Redundancy Group has gone down.
l
A tracked object (interface or IP address)
in the Router Redundancy Group has
gone down.
The group is routing packets properly.
RrgMultiplePrimary
Indicates that multiple primary devices (for
example, HSRP Active or VRRP Master) are
identified in a Router Redundancy Group.
Typically, the protocol-specific
communication between routers in the group
is malfunctioning.
RrgMultipleSecondary
Page 333 of 1087
Indicates that more than one secondary
device (HSRP Standby ) is identified in a
Router Redundancy Group. Note: This
incident applies only to Router Redundancy
Groups using the HSRP protocol. VRRP
allows more than one secondary role (VRRP
Standby State) . Typically, the protocolspecific communication between routers in
the group is malfunctioning.
Rate
Configuration
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
RrgNoPrimary
Indicates that no primary device (for
example, HSRP Active or VRRP Master) is
identified in a Router Redundancy group.
Rate
Configuration
This incident typically indicates one of the
following:
RrgNoSecondary
l
Too many routers are down.
l
Protocol-specific communication
between routers in the group is
malfunctioning.
Indicates that no secondary device (for
example, HSRP Standby or VRRP Backup)
is identified in a Router Redundancy Group.
This incident typically indicates the following:
RrgSecondaryChanged
l
Protocol-specific communication
between routers in the group is
malfunctioning.
l
The group is routing packets properly
because a single primary device has
been identified.
Indicates that a secondary role (for example,
HSRP Standby or VRRP Backup) moved
from one device to another in a Router
Redundancy Group.
This incident typically indicates the following:
l
An router or interface in the Router
Redundancy Group has gone down.
l
A tracked object (interface or address)
has gone down.
l
The group is routing packets properly.
SNMPTrapLimitCritical
Indicates the number of SNMP traps
persisted in the NNMi database is
approaching the maximum allowed limit.
After the maximum allowed limit is reached,
NNM no longer accepts SNMP traps until the
number of SNMP traps within the database is
reduced using the nnmtrimincidents.ovpl
command.
SNMPTrapLimitMajor
Indicates the number of SNMP traps
persisted in the NNMi database has reached
or exceeded 95% of the maximum limit. After
the maximum limit is reached, NNMi only
accepts traps required for Causal Engine
analysis until the number of SNMP traps
Page 334 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
Rate
Configuration
within the database has been reduced using
the nnmtrimincidents.ovpl command.
SNMPTrapLimitWarning
Indicates the number of SNMP traps
persisted in the NNMi database has reached
or exceeded 90% of the maximum limit. After
the maximum limit is reached, NNMi no
longer accepts SNMP traps until the number
of SNMP traps within the database is
reduced using the nnmtrimincidents.ovpl
command.
TemperatureOutOfRangeOrMalfunctioning
Indicates the specified temperature sensor
on the Source Node is too hot or too cold.
TrapStorm
Indicates a trap storm has occurred.
VoltageOutOfRangeOrMalfunctioning
Indicates the specified voltage on one of the
Source Node's power supplies is out of
range.
(HP Network Node Manager iSPI Performance for Metrics Software) For network performance monitoring,
the HP Network Node Manager iSPI Performance for Metrics Software software provides additional
management event configurations. Click here for more information.
Each of these configurations has a Category value of Performance, a Family value of Interface, and a
Nature of Root Cause.
Additional Management Event Configurations (HP Network Node Manager iSPI Performance for
Metrics Software)
Incident Configuration Name
Description
InterfaceInputDiscardRateHigh
Indicates a high input discard rate on the interface. This
rate is based on the reported change in the number of
input packets on the interface and the discarded packet
count.
IntefaceInputErrorRateHigh
Indicates a high input error rate on the interface. This
rate is based on the reported change in the number of
input packets on the interface and the packet error
count.
InterfaceInputUtilizationHigh
Indicates a high input utilization on the interface. This
percentage is based on the interface speed and the
reported change in the number of input bytes on the
interface.
InterfaceInputUtilizationLow
Indicates a low input utilization on the interface. This
percentage is based on the interface speed and the
reported change in the number of input bytes on the
interface.
InterfaceInputUtilizationNone
Indicates there is no input utilization on the interface.
This value is based on the interface speed and the
Page 335 of 1087
Rate
Configuration
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Incident Configuration Name
Description
Rate
Configuration
reported change in the number of input bytes on the
interface.
InterfaceOutputDiscardRateHigh
Indicates a high output discard rate on the interface.
This rate is based on the reported change in the
number of input packets on the interface and the
discarded packet count.
InterfaceOutputErrorRateHigh
Indicates a high output error rate on the interface. This
rate is based on the reported change in the number of
output packets on the interface and the packet error
count.
InterfaceOutputUtilizationHigh
Indicates a high output utilization on the interface. This
percentage is based on the interface speed and the
reported change in the number of output bytes on the
interface.
InterfaceOutputUtilizationLow
Indicates a low output utilization on the interface. This
percentage is based on the interface speed and the
reported change in the number of output bytes on the
interface.
InterfaceOutputUtilizationNone
Indicates there is no output utilization on the interface.
This value is based on the interface speed and the
reported change in the number of output bytes on the
interface.
InterfacePerformanceCritical
Indicates that the interface performance has reached a
Critical severity.
InterfacePerformanceWarning
Indicates that the interface performance has reached a
Warning severity.
Incident Pair (Pairwise) Configurations Provided by NNM
NNM provides the pairwise configurations described in the following table.
Pairwise Configurations Provided by NNM
Name
Description
CiscoLinkDownUpPair
Cancels a CiscoLinkDown incident with a CiscoLinkUp
incident on the same interface for the same SNMP agent
address.
This configuration is used for known Cisco devices.
CiscoModuleDownUpPair
Not yet implemented.
OvApaAddressDownUpPair
Cancels an NNM 6.x or 7.x Node Down event with a NNM 6.x
or 7.x Node Up event from the same SNMP agent address.
OvApaAggPortConnDownUpPair
Cancels an NNM 6.x or 7.x APA Aggregate Port Connection
Down event with an NNM 6.x or 7.x APA Aggregate Port
Page 336 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
Connection Up event.
OvApaAggPortDegradeNotDegradePair
Cancels an NNM 6.x or 7.x APA Aggregate Port Degraded
event with an NNM 6.x or 7.x APA Aggregate Port Not
Degraded event on the same interface for the same SNMP
agent address.
OvApaAggPortDownUpPair
Cancels of an NNM 6.x or 7.x APA Aggregate Port Down event
with an NNM 6.x or 7.x APA Aggregate Port Up event on the
same interface for the same SNMP agent address.
OvApaBoardDownUpPair
Cancels an NNM 6.x or 7.x APA Board Down event with an
NNM 6.x or 7.x APA Board Up event from the same SNMP
agent address.
OvApaConnDownUpPair
Cancels an NNM 6.x or 7. x APA Address Down event with an
NNM 6.x or 7.x APA Address Up event on the same address
for the same SNMP agent address.
OvApaIfDownUpPair
Cancels an NNM 6.x or 7.x APA If Down event with an NNM
6.x or 7.x APA If Up event on the same interface for the same
SNMP agent address.
OvApaNodeDownUpPair
Cancels an NNM 6.x or 7.x APA Node Down event with an
NNM 6.x or 7.x APA Node Up event from the same SNMP
agent address.
OvIfDownUpPair
Cancels an NNM 6.x or 7.x If Down event with an NNM 6.x or
7.x If Up event on the same interface for the same SNMP agent
address.
OvNodeDownUpPair
Cancels an NNM 6.x or 7.x Node Down event with an NNM 6.x
or 7.x Node Up event from the same SNMP agent address.
RcAggLinkDownUpPair
Cancels an RcAggLinkDown incident with an RcAggLinkUp
incident from the same Multi-Link Trunk (MLT) Aggregator ID
(from the MIB) and SNMP agent address.
RcChasFanDownUpPair
Cancels an RcChasFanDown incident with an RcChasFanUp
incident from the same fan ID (from the MIB) and SNMP agent
address.
RcChasPowerSupplyDownUpPair
Cancels an RcChasPowerSupplyDown incident with an
RcChasPowerSupplyUp incident from the same power supply
ID (from the MIB) and SNMP agent address.
RcSmltIsLinkDownUpPair
Cancels an RcSmltIstLinkDown incident with an
RcSmltIstLinkUp incident from the same SNMP agent address.
RcnAggLinkDownUpPair
Cancels an RcnAggLinkDown incident with an RcnAggLinkUp
incident from the same Multi-Link Trunk (MLT) Aggregator Link
ID (from the MIB) and SNMP agent address.
RcnChasFanDownUpPair
Cancels an RcnChasFanDown incident with an
RcnChasFanUp incident from the same fan ID (from the MIB)
and SNMP agent address.
Page 337 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
RcnChasPowerSupplyDownUpPair
Cancels an RcnChasPowerSupplyDown incident with an
RcnChasPowerSupplyUp incident from the same power
supply ID (from the MIB) and SNMP agent address.
RcnSmltIsLinkDownUpPair
Cancels an RcnSmltIstLinkDown incident with an
RcnSmltIstLinkUp incident from the same SNMP agent
address.
SnmpLinkDownUpPair
Cancels an SNMPLinkDown incident with an SNMPLinkUp
incident on the same interface for the same SNMP agent
address.
To see or modify these incident pair configurations:
1. Navigate to the Incident Configuration view.
a. In the Workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the Pairwise Configuration tab.
3. Select the configuration you want to see or modify, and click
configuration.
Open to see or change the
In the Pairwise Configuration form, click Help→ Using the Pairwise Configuration form for more
information.
4. When you are finished, click
Configuration form.
Save and Close to save your changes and return to the Incident
Manage the Number of Incoming Incidents
NNMi's Causal Engine reduces the number of incidents by extensively evaluating problems and
determining the root cause for you, whenever possible.
To help simplify the diagnosis of network faults, you can configure NNMi to manage the number of
incidents that are displayed. To do so, use any of the following methods:
l
Disable the Incident configuration. In the Basics group of the Incident Configuration form, verify that
Enabled is cleared for each configuration for which you do not want NNMi to generate an Incident.
l
Use NNMi's Management Mode feature to set the Management Mode of the network object to Not
Managed or Out of Service. NNMi discards any incoming traps if the Source Node or Source Object is
Unmanaged1. See "Stop or Start Managing a Node, Interface, Card, Address, or Node Component"
(on page 248) for more information.
l
Use the Monitoring Configuration to specify that you do not want NNMi to monitor the network
object. NNMi discards any incoming traps if the Source Node or Source Object is not monitored. See
"Configure Monitoring Behavior" (on page 214) for more information.
l
Identify additional criteria for or relationships between incoming incidents. When these criteria or
1Indicates the Management Mode is "Not Managed" or "Out of Service".
Page 338 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
relationships occur, NNMi modifies the flow of incidents by recognizing the criteria or patterns of
incoming management events or SNMP traps and nesting related incidents as correlated children.
These strategies can dramatically reduce the number of incidents and improve the value of the incidents
displayed. For example, instead of displaying an entire incident storm typically generated by equipment
and link failures, use the deduplication configuration to specify only the most meaningful incidents, and
correlate the rest as children. Then it is faster and easier to identify the network problem. See "Establish
Criteria or Relationships for Incoming Incidents" (on page 339) for more information.
Related Topics
"Configure Management Events" (on page 724)
"Configure SNMP Trap Incidents" (on page 432)
Establish Criteria or Relationships for Incoming Incidents
Using NNMi, you can establish the criteria or relationships for the incoming incidents using any of the
incident configurations shown in the following diagram and explained in the table below. You can choose
to use them as is, edit them, or create your own configurations. You can also create your own Custom
Correlations. See "Configure Custom Correlations" (on page 353) for more information about Custom
Correlations.
Overview of Incident Configuration Options
Configuration
Option
When to Use
1
Interface
Settings
Page 339 of 1087
Select this tab to specify that you want to configure
Suppression, Enrichment, Dampening, and Actions for a
specified Interface Group.
Example
Change the Severity
and Message of an
incident
configuration for a
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Configuration
When to Use
Option
Example
specified Interface
Group.
Dampen an Interface
Down incident only
for the interfaces in a
specified Interface
Group that you know
will be intermittently
unavailable.
2
Node Settings
Select this tab to specify that you want to configure
Suppression, Enrichment, Dampening, Actions, and
Diagnostic Selections for a specified Node Group.
Change the Severity
and Message of an
incident
configuration for the
nodes in a specified
Node Group.
3
Suppression
Select this tab when you want to discard an incident before
it appears in an incident view.
Discard an incident if
it is in response to a
particular status
change notification
trap.
4
Enrichment
Select this tab when you want to fine tune any of the
following for a selected incident configuration:
Change the Severity
and Message of an
incident
configuration.
5
Dampening
l
Category
l
Family
l
Severity
l
Priority
l
Correlation Nature
l
Message
l
Assigned To
l
Add a node or interface Custom Attribute to an incident
Select this tab to delay (dampen) the following for an
incident configuration:
l
Appearance within Incident views in the NNMi Console
l
Execution of Incident Actions
l
Execution of Diagnostics (NNM iSPI NET)
Lengthen the
Dampen Interval for
the Interface Down
incident
Configuration
provided by NNMi.
Disable Dampening
for the Interface
Down Incident
Configuration
provided by NNMi.
Page 340 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Configuration
When to Use
Option
6
Deduplication
Select this tab to correlate incidents that are identified as
duplicates based on one or more Custom Incident Attribute
(CIA) or SNMP trap varbind values.
To help your operators understand the magnitude or
significance of the problem, NNMi tracks the number of
duplicates generated. This value is captured as the
Duplicate Count attribute. It is incremented on the Duplicate
Correlation incident. Its Correlation Nature attribute value is
Dedup Correlation.
NNMi also records the following information related to
duplicate incidents:
First Occurrence Time: Indicates the timestamp of the first
occurrence of a duplicate incident.
Last Occurrence Time: Indicates the timestamp of the
latest notification for a set of duplicate incidents.
Count: Specifies the number of duplicate incidents for the
current configuration that NNMi stores at one time. For
example, if the Count is 10, after NNMi receives 10
duplicate incidents, NNMi deletes the first (oldest) duplicate
incident and keeps the eleventh. (NNMi stores ten
maximum.)
Note: A Duplicate Correlation incident inherits the
Dampening settings of its Correlated Children. If the
Correlated Children are Closed while Dampened,
and therefore deleted, NNMi retains the parent
Duplicate Correlation incident. See "Dampening
Incident Configurations" (on page 353) for more
information about Dampening an Incident
Configuration.
Page 341 of 1087
Example
Identify any
CiscoLinkDown
incidents as
duplicates if the cia_
address value is the
same for the
incident’s Source
Object.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Configuration
When to Use
Option
7
Rate
Example
Select this tab to measure the rate of incoming incidents
If a connection is
within a defined time period and correlate any incidents that intermittently down
occur within the specified time period.
three times within 30
minutes; correlate
NNMi stores the following information related to rate:
the Connection
Down incidents.
Count: Indicates the rate at which the incident must occur
within the specified timeframe.
Hours, Minutes, and Seconds: Used to measure the time
within the rate must occur
First Occurrence Time: Indicates the time at which the
measured rate was reached.
Last Occurrence Time: Indicates the last time which the
incident occurred.
NNMi updates the Correlation Notes with the number of
incidents that have occurred within the specified time
period. For example, 5 in 5 minutes.
Note: A Rate Correlation incident inherits the Dampening
settings of its Correlated Children. If the Correlated
Children are Closed while Dampened, and therefore
deleted, NNMi retains the parent Rate Correlation
incident. See "Dampening Incident Configurations"
(on page 353) for more information about
Dampening an Incident Configuration.
8
Actions
Select this tab to configure actions to automatically run at
any point in the incident lifecycle. For example, you might
want to configure an action to occur when an incident of the
type you are configuring is generated (Registered).
When an incident is
generated
(Registered), open a
trouble ticket.
After the incident is
Closed, close the
trouble ticket.
9
Forward to
Global
Managers
NNMi Advanced - Global Network Management feature).
Select the Global Manager Forwarding tab when you want
to forward specific SNMP traps from your NNMi
management server (a Regional Manager) to all Global
Managers in your Global Network Management
environment.
Forward all
CiscoLinkDown
incidents to the
Global Manager.
10
Pairwise
Select this tab to pair the first occurrence of an incident to
another subsequent incident.
Correlate a
CiscoLinkDown
incident as the Child
Incident for a
CiscoLinkUp
incident.
Note: NNMi provides Correlation Notes information only
when the Causal Engine has analyzed and Closed
the incident. Software that is integrated with NNMi
might also provide information identifying the reason
an incident was Closed. Any time an incident is
Closed manually (for example, by the network
operator), NNMi does not provide Correlation Notes
information.
Page 342 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Configuration
When to Use
Option
Example
NNMi also enables you to create your own Custom Correlations as described in the following table.
Custom Correlation Configuration Options
Configuration Description
Custom
Correlations
Enables you to correlate incidents using regular expressions to define the relationships
between Parent and Child Incidents. This feature is useful when you want to define a
relationship between a number of incidents potentially from different network objects
that form a logical set to identify a problem. The set of correlations is considered
complete if all of the incidents arrive within a specified time window.
When configuring a Custom Correlation, you select the Parent and Child Incident
configurations, the time window, and the regular expression that defines the relationship
requirements that must be met before the incidents are correlated. See "Configure
Custom Correlations" (on page 353) for more information about Custom Correlations.
See "Configuring Incidents" (on page 304) for more information about the Incident Configuration options.
See "Load SNMP Trap Incident Configurations" (on page 425) for more information about how to specify
which SNMP traps you want to receive by automatically creating or updating an incident configuration for
an SNMP trap using a MIB file.
Related Topics
"Configure Management Events" (on page 724)
"Configure SNMP Trap Incidents" (on page 432)
"Configure Remote NNM 6.x/7.x Events" (on page 579)
Correlate Duplicate Incidents (Deduplication Configuration)
The deduplication configuration determines what values NNMi should match to detect when an SNMP
trap, management event, or remote NNM 6.x/7.x event is a duplicate.
You can provide the required information within the following contexts:
"Deduplication Comparison Parameters Form (SNMP Trap Incident)" (on page 562)
"Deduplication Comparison Parameters Form (Remote NNM 6.x/7.x Events)" (on page 707)
"Deduplication Comparison Parameters Form (Management Events)" (on page 841)
Deduplication Comparison Parameters Form
Custom Incident Attributes (CIAs) are used as parameter values. Parameter values enable accurate
identification of duplicate incidents. There are two categories of CIAs:
l
SNMP trap varbind values (Name = the MIB varbind identifier, Type = asn_*)
l
Custom attributes provided by NNMi (Name = cia.*, Type=String). See "Custom Incident Attributes
Provided by NNMi (for Administrators)" (on page 310).
You can provide the required information within the following contexts:
"Deduplication Comparison Parameters Form (SNMP Trap Incident)" (on page 562)
Page 343 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
"Deduplication Comparison Parameters Form (Remote NNM 6.x/7.x Events)" (on page 707)
"Deduplication Comparison Parameters Form (Management Events)" (on page 841)
Track Incident Frequency (Rate: Time Period and Count)
Use Rate Configuration to track incident patterns based on the number of incident reoccurrences within a
specified time period. After the count within the specified time period is reached, NNMi emits a Rate
Correlation incident and continues to update the Correlation Notes with the number of occurrences within
that rate.
You can provide the required information within the following contexts:
"Configure Rate (Time Period and Count) for an SNMP Trap Incident" (on page 563)
"Configure Rate (Time Period and Count) for a Remote NNM 6.x/7.x Event Incident" (on page 708)
"Configure Rate (Time Period and Count) for a Management Event Incident" (on page 842)
Rate Comparison Parameters Form
Custom Incident Attributes (CIAs) are used as parameter values. Parameter values enable accurate
identification of duplicate incidents. There are two categories of CIAs:
l
SNMP trap varbind values (Name = the MIB varbind identifier, Type = asn_*)
l
Custom attributes provided by NNMi (Name = cia.*, Type=String). See "Custom Incident Attributes
Provided by NNMi (for Administrators)" (on page 310).
You can provide the required information within the following contexts:
"Rate Comparison Parameters Form (SNMP Trap Incident)" (on page 565)
"Rate Comparison Parameters Form (Remote NNM 6.x/7.x Events)" (on page 710)
"Rate Comparison Parameters Form (Management Events)" (on page 844)
About Pairwise Configurations
Often two incidents have a logical relationship to each other, for example, CiscoLinkDown followed by
CiscoLinkUp. There is no need for both incidents to take up room in your Incident view. Nesting the two
together helps you do your job quickly and efficiently.
Use the Pairwise Configuration to pair up the occurrence of one incident with another subsequent incident.
When the second incident in the pair occurs, the first incident becomes a correlated child incident within
the parent incident (see illustration below). See "Incident Pair (Pairwise) Configurations Provided by NNM"
(on page 345) for ideas.
Page 344 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
NNM automatically ensures that the Source Node attribute value is identical in both incidents of your
defined pair. Some incident pairs require extensive details to verify an accurate match. If both sample
incidents have custom incident attributes, you can refine the match criteria beyond Source Node. See "Pair
Item Configuration Form (Identify Incident Pairs)" (on page 350).
Related Topics:
"Prerequisites for Pairwise Configurations" (on page 347)
"Pairwise Configuration Form (Correlate Pairs of Incidents)" (on page 348)
Incident Pair (Pairwise) Configurations Provided by NNM
NNM provides the pairwise configurations described in the following table.
Pairwise Configurations Provided by NNM
Name
Description
CiscoLinkDownUpPair
Cancels a CiscoLinkDown incident with a CiscoLinkUp
incident on the same interface for the same SNMP agent
address.
This configuration is used for known Cisco devices.
CiscoModuleDownUpPair
Not yet implemented.
OvApaAddressDownUpPair
Cancels an NNM 6.x or 7.x Node Down event with a NNM 6.x
or 7.x Node Up event from the same SNMP agent address.
OvApaAggPortConnDownUpPair
Cancels an NNM 6.x or 7.x APA Aggregate Port Connection
Down event with an NNM 6.x or 7.x APA Aggregate Port
Connection Up event.
OvApaAggPortDegradeNotDegradePair
Cancels an NNM 6.x or 7.x APA Aggregate Port Degraded
event with an NNM 6.x or 7.x APA Aggregate Port Not
Degraded event on the same interface for the same SNMP
agent address.
Page 345 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
OvApaAggPortDownUpPair
Cancels of an NNM 6.x or 7.x APA Aggregate Port Down event
with an NNM 6.x or 7.x APA Aggregate Port Up event on the
same interface for the same SNMP agent address.
OvApaBoardDownUpPair
Cancels an NNM 6.x or 7.x APA Board Down event with an
NNM 6.x or 7.x APA Board Up event from the same SNMP
agent address.
OvApaConnDownUpPair
Cancels an NNM 6.x or 7. x APA Address Down event with an
NNM 6.x or 7.x APA Address Up event on the same address
for the same SNMP agent address.
OvApaIfDownUpPair
Cancels an NNM 6.x or 7.x APA If Down event with an NNM
6.x or 7.x APA If Up event on the same interface for the same
SNMP agent address.
OvApaNodeDownUpPair
Cancels an NNM 6.x or 7.x APA Node Down event with an
NNM 6.x or 7.x APA Node Up event from the same SNMP
agent address.
OvIfDownUpPair
Cancels an NNM 6.x or 7.x If Down event with an NNM 6.x or
7.x If Up event on the same interface for the same SNMP agent
address.
OvNodeDownUpPair
Cancels an NNM 6.x or 7.x Node Down event with an NNM 6.x
or 7.x Node Up event from the same SNMP agent address.
RcAggLinkDownUpPair
Cancels an RcAggLinkDown incident with an RcAggLinkUp
incident from the same Multi-Link Trunk (MLT) Aggregator ID
(from the MIB) and SNMP agent address.
RcChasFanDownUpPair
Cancels an RcChasFanDown incident with an RcChasFanUp
incident from the same fan ID (from the MIB) and SNMP agent
address.
RcChasPowerSupplyDownUpPair
Cancels an RcChasPowerSupplyDown incident with an
RcChasPowerSupplyUp incident from the same power supply
ID (from the MIB) and SNMP agent address.
RcSmltIsLinkDownUpPair
Cancels an RcSmltIstLinkDown incident with an
RcSmltIstLinkUp incident from the same SNMP agent address.
RcnAggLinkDownUpPair
Cancels an RcnAggLinkDown incident with an RcnAggLinkUp
incident from the same Multi-Link Trunk (MLT) Aggregator Link
ID (from the MIB) and SNMP agent address.
RcnChasFanDownUpPair
Cancels an RcnChasFanDown incident with an
RcnChasFanUp incident from the same fan ID (from the MIB)
and SNMP agent address.
RcnChasPowerSupplyDownUpPair
Cancels an RcnChasPowerSupplyDown incident with an
RcnChasPowerSupplyUp incident from the same power
supply ID (from the MIB) and SNMP agent address.
RcnSmltIsLinkDownUpPair
Cancels an RcnSmltIstLinkDown incident with an
RcnSmltIstLinkUp incident from the same SNMP agent
Page 346 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
address.
SnmpLinkDownUpPair
Cancels an SNMPLinkDown incident with an SNMPLinkUp
incident on the same interface for the same SNMP agent
address.
To see or modify these incident pair configurations:
1. Navigate to the Incident Configuration view.
a. In the Workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the Pairwise Configuration tab.
3. Select the configuration you want to see or modify, and click
configuration.
Open to see or change the
In the Pairwise Configuration form, click Help→ Using the Pairwise Configuration form for more
information.
4. When you are finished, click
Configuration form.
Save and Close to save your changes and return to the Incident
Prerequisites for Pairwise Configurations
NNMi automatically ensures that the Source Node attribute value is identical in both incidents of your
defined pair.
If you need to provide more details to accurately identify the logical pair of incidents (from among all
possible incidents related to that source node), complete the Optional step 6 below.
Complete the following steps before attempting to set up a Pairwise Configuration:
1. Identify the two incidents or SNMP traps that consist of the logical relationship that makes the pair.
2. Configure those two incidents or traps within NNMi, if they are not already configured:
n
See "Incident Configurations Provided by NNMi" (on page 310).
n
See "Configure SNMP Trap Incidents" (on page 432).
n
See "Configure Remote NNM 6.x/7.x Events" (on page 579).
3. Generate one of each of the two incidents or SNMP traps so you can see an example of each in one
of the NNMi Incident views. See "Views Provided by NNMi".
4. Select the first sample incident for the pair, and click
Open to display the Incident form.
Navigate to the Custom Attributes tab. These are the custom incident attributes available to use in
step 6, below. See "Custom Incident Attributes Provided by NNMi (for Administrators)" (on page 310)
for more information about Custom Attributes.
Page 347 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
5. Repeat the previous step with the second sample incident for the pair.
6. Optional. If both sample incidents have custom attributes, you can refine the match criteria beyond
Source Node. Some incident pairs require extensive details to verify an accurate match. See
"Pairwise Configuration Form (Correlate Pairs of Incidents)" (on page 348).
Pairwise Configuration Form (Correlate Pairs of Incidents)
Use the Pairwise Configuration to pair the occurrence of one incident with another subsequent incident.
See "About Pairwise Configurations" (on page 344) for more information.
To configure incident pairs:
1. Complete the steps in "Prerequisites for Pairwise Configurations" (on page 347) so you know exactly
which two incidents or traps belong to this logical pair.
2. Navigate to the Pairwise Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
c. Navigate to the Pairwise Configuration tab.
d. Do one of the following:
o To create a new pair configuration, click the
o To edit an existing pair configuration, click the
New icon, and continue.
Open icon in the row representing the
configuration you want to edit, and continue.
o To delete a pair configuration, select a row and click the
Delete icon.
3. Provide the basic definition of the pair of incidents for this correlation (see table).
4. NNM automatically ensures that the Source Node attribute value is identical in both incidents of your
Page 348 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
defined pair. Some incident pairs require extensive details to verify an accurate match. If both sample
incidents have custom incident attributes, you can refine the match criteria beyond Source Node.
Optional. Navigate to the Pair Items tab, and provide one or more custom incident attribute sets for
NNMi to use as a filter when identifying a valid pair of incidents. See "Pair Item Configuration Form
(Identify Incident Pairs)" (on page 350).
Then, click
Save and Close to save your changes and return to the previous configuration form.
For example:
n
If you specify a First In Pair and Second In Pair of .1.3.6.1.2.1.2.2.1.1, the first incident's varbind
value for the specified OID must match the second incident's varbind value for the specified OID
to confirm a match.
n
If you specify two custom attribute sets (one with both First In Pair and Second In Pair set to
position 7, and one with both First In Pair and Second In Pair set to position 25), then the values
for both custom attributes (varbind position 7 and varbind position 25) in both Incidents must
match to confirm the logical pair.
The next time the two incidents in this pair are generated, the first one becomes a Child Incident of
the second one. See "About Pairwise Configurations" (on page 344) for an example.
Pairwise Configuration Definition
Attribute
Description
Name
The name is used to identify the pairwise configuration and must be unique. Use a name
that will help you to remember the purpose for this pairwise configuration.
Maximum length is 64 characters. Alpha-numeric and special characters (~ ! @ # $ % ^ &
* ( ) _+) are allowed. No spaces are allowed.
Enable
In the Basics group, verify that Enable
First Incident
Configuration
Identify the incident in the pair that would occur first in the logical sequence. Click the
Lookup icon and select
Quick Find. Choose the name of one of the predefined
incident configurations. If you cannot find it, see:
Second
Incident
Configuration
Description
is selected.
l
See "Incident Configurations Provided by NNMi" (on page 310).
l
See "Configure SNMP Trap Incidents" (on page 432).
l
See "Configure Remote NNM 6.x/7.x Events" (on page 579).
Identify the incident in the pair that would occur second in the logical sequence.Click the
Lookup icon and select
Quick Find. Choose the name of one of the predefined
incident configurations. If you cannot find it, see:
l
See "Incident Configurations Provided by NNMi" (on page 310).
l
See "Configure SNMP Trap Incidents" (on page 432).
l
See "Configure Remote NNM 6.x/7.x Events" (on page 579).
Optional. Explain the purpose of your pairwise configuration for future reference.
Type a maximum of 1024 characters. Alpha-numeric, spaces, and special characters (~ !
@ # $ % ^ & * ( ) _+) are allowed.
Author
Indicates who created or last modified the Correlation Rule.
See Author form for important information.
Page 349 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Caution: If the Author attribute value is HP Network Node Manager, any changes are at
risk of being overwritten in the future.
Click the
values or click
Lookup icon and select
Quick Find to access the list of existing Author
New to create one.
Pair Item Configuration Form (Identify Incident Pairs)
NNMi automatically ensures that the Source Node attribute value is identical in both incidents in your
defined pair. Some incident pairs require extensive details to verify an accurate match. If both sample
incidents have custom incident attributes, you can use the Pair Item Configuration form to refine the match
criteria beyond Source Node.
Specify one or more values for NNMi to use as a filter when identifying a valid pair of incidents.
You can use any Custom Incident Attributes (CIAs) displayed on the Incident form of the two incidents you
are associating into a logical pair. The group of available CIAs depends on which incidents you select.
There are two categories of possible CIAs:
l
SNMP trap varbinds identified by the Abstract Syntax Notation value (ASN.1) or position. For example,
a varbind OID of .1.3.6.1.2.1.2.2.1.1 or a position number of 25.
l
Custom attributes provided by NNMi (Name = cia_*). See "Custom Incident Attributes Provided by
NNMi (for Administrators)" (on page 310).
The group of available CIAs depends on which incident you are configuring (for example,
CiscoLinkDown). To see which CIAs are available, navigate to an Incident view, select an instance of
that incident-type, click the
Open icon and navigate to the Custom Attributes tab. The items listed in
the table are the CIAs for that particular incident-type. For example, all CiscoLinkDown incidents would
have the same group of CIAs shown in the illustration below.
To configure which attributes NNMi uses to verify incident identity:
Page 350 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
1. Complete the steps in "Prerequisites for Pairwise Configurations" (on page 347) so your choices for
this Item Pair configuration are displayed in the NNMi console. (Two Incident forms should be open
before you proceed to step 2.)
2. Navigate to the Pair Item Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
c. Navigate to the Pairwise Configuration tab.
d. Do one of the following:
o To create a new pair configuration, click the
o To edit a pair configuration, click the
New icon.
Open icon in the row representing the
configuration you want to edit.
e. On the Pairwise Configuration form, locate the Pair Items tab.
f. Do one of the following:
o To create a new pair item configuration, click the
o To edit a pair item configuration, click the
New icon.
Open icon in the row representing the
configuration you want to edit.
3. Specify the attributes you want NNMi to use to confirm the identity of the pair of incidents (see table).
4. Click
Save and Close to save your changes and return to the previous form.
5. Repeat steps 1-3 any number of times. The incidents must pass all Pair Item criteria, plus have
identical Source Node attribute values.
Pair Item Configuration
Attribute
Description
First In
Pair
Type the specification required to confirm the identify of the first incident in this logical pair of
incidents. Provide one of the following:
l
The SNMP trap varbind Abstract Syntax Notation value - ASN.1 (OID)
l
The SNMP trap varbind position number
Caution: The varbind position numbers are not visible in the table on the Incident form's
Custom Attributes tab. And the rows in that table are sorted by the visible column
headings and are not in varbind position order. You must access the vendorsupplied information in the underlying MIB file to determine the appropriate
position number for any particular varbind.
l
Second
In Pair
The Custom Attribute Name value (see "Custom Incident Attributes Provided by NNMi (for
Administrators)" (on page 310) or the Name column in the table on the Incident Form:
Custom Attributes Tab of the Incident you are configuring as a member of this logical
pair).
Type the specification required to confirm the identify of the second incident in this logical
pair of incidents. Provide one of the following:
l
The SNMP trap varbind Abstract Syntax Notation value - ASN.1 (OID)
l
The SNMP trap varbind position number
Page 351 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Caution: The varbind position numbers are not visible in the table on the Incident form's
Custom Attributes tab. And the rows in that table are sorted by the visible column
headings and are not in varbind position order. You must access the vendorsupplied information in the underlying MIB file to determine the appropriate
position number for any particular varbind.
l
The Custom Attribute Name value (see "Custom Incident Attributes Provided by NNMi (for
Administrators)" (on page 310) or the Name column in the table on the Incident Form:
Custom Attributes Tab of the Incident you are configuring as a member of this logical
pair).
Related Topics
"Incident Pair (Pairwise) Configurations Provided by NNM" (on page 345)
Suppress Incident Configurations
NNMi enables you to suppress incidents based on Interface Group, Node Group, or default Suppression
settings. NNMi applies your Suppression settings in the following order. Only the first match applies.
1. Interface Group (SNMP Trap Configuration Form: Interface Settings tab)
2. Node Group (SNMP Trap Configuration Form: Node Settings tab)
3. Enrich configuration settings without specifying an Interface Group or Node Group (SNMP Trap
Configuration Form: Enrichment tab)
You can provide the required information within the following contexts:
"Configure Suppression Settings for an SNMP Trap Incident"
"Configure Suppression Settings for a Management Event Incident" (on page 811)
"Configure Suppression Settings for a Remote NNM 6.x/7.x Event Incident" (on page 671)
Enrich Incident Configurations
NNMi enables you to fine tune and enhance incidents based on Interface Group, Node Group, or default
Enrichment settings. NNMi applies your Enrichment settings in the following order. Only the first match
applies:
1. Interface Group (Interface Settings tab)
2. Node Group (Node Settings tab)
3. Enrich configuration settings without specifying an Interface Group or Node Group (Enrichment tab)
The types of items you can fine tune and enhance for a selected incident configuration, include:
l
Category
l
Family
l
Severity
l
Priority
l
Correlation Nature
Page 352 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
l
Message
l
Assigned To
Note: Any configuration you specify for Severity, Priority, or Message overrides those values provided in
the Basics information.
You can provide the required information within the following contexts:
"Configure Enrichment Settings for an SNMP Trap Incident" (on page 537)
"Configure Enrichment Settings for a Management Event Incident" (on page 822)
"Configure Enrichment Settings for a Remote NNM 6.x/7.x Event Incident" (on page 680)
Dampening Incident Configurations
NNMi enables you to delay (dampen) the following for an incident configuration:
l
Appearance within Incident views in the NNMi Console
l
Execution of Incident Actions
l
Execution of Diagnostics (HP Network Node Manager iSPI Network Engineering Toolset Software \
NNM iSPI NET)
You can provide the required information within the following contexts:
"Configure Dampening Settings for an SNMP Trap Incident" (on page 540)
"Configure Dampening Settings for a Management Event Incident" (on page 825)
"Configure Dampening Settings for a Remote NNM 6.x/7.x Event Incident" (on page 683)
Configure Custom Correlations
For information about each Custom Correlation Configuration tab:
NNMi enables you to correlate groups of incidents under a Parent Incident. This feature is useful when you
want to define a relationship between a number of incidents potentially from different network objects that
form a logical set to identify a problem. The set of correlations is considered complete if all of the incidents
arrive within a specified time window.
When configuring a Custom Correlation, you configure one or both of the following:
Rule
Description
Correlation
Rule
Tip: Configure a Correlation Rule when you want to correlate only one type of Child
incident Configuration with a Parent Incident Configuration that is generated by NNMi.
Use a Correlation Rule to specify the following:
l
Parent Incident Configuration
l
Child Incident Configuration
l
Filters that NNMi should use when selecting the Parent and Child Incident instances for
correlation
l
The time window within which NNMi begins to correlate the incidents.
Note: If the Parent and Child incidents occur within the Correlation Window Duration
specified, NNMi begins to correlate the incidents as soon as they occur.
Page 353 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Rule
Description
l
The regular expression (Correlation Filter) that defines the relationship requirements
that must be met before the incidents are correlated
The Parent and Child Incident do not have to be the same incident configuration. For
example, you can correlate an Address Not Responding incident with an Interface Down
incident.
See "Correlation Rule Example" (on page 379) for a step-by-step example of how the
Subinterface Correlation Rule provided by NNMi was created.
Causal
Rule
Tip: Configure a Causal Rule when you want to cause NNMi to generate a Parent Incident
and you want to correlate one or more Child Incident Configurations under the Parent
Incident that you cause to be generated.
Use a Causal Rule to specify the following:
l
Parent Incident Configuration to be generated
l
One or more Child Incident Configurations to be correlated under the generated Parent
Incident
l
Filters that NNMi should use when selecting the Child Incident instances for correlation
l
Source Object and Source Node filters to be used to determine the Source Node and
Source Object for the generated Parent Incident
l
The time window that must be met before NNMi correlates the incidents.
Note: NNMi waits until the Correlation Window Duration has passed before generating
the Parent Incident and correlating its Child Incidents.
To establish a relationship between multiple Custom Correlations, configure a Causal Rule
to generate a Parent Incident that becomes the Child Incident of another Parent Incident.
See "Causal Rule Example" for a step-by-step example of creating a Causal Rule.
To configure a Custom Correlation:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. View the configured attributes (see table).
3. Do one of the following, or both:
n
Configure one or more Correlation Rules. See "Configure a Correlation Rule" (on page 355) for
more information.
n
Configure one or more Causal Rules. See "Configure a Causal Rule" (on page 382) for more
information.
4. Click
Save and Close to save your changes and return to the previous form.
Custom Correlation Registration Attribute
Attribute
Description
Last Modified
The date and time the Custom Correlation configuration was last modified.
Page 354 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Configure a Correlation Rule
Tip: Configure a Correlation Rule when you want to correlate a Child incident Configuration under a
Parent Incident Configuration that is generated by NNMi.
Note: See Help → Documentation Library → Release Notes, and locate the Support Matrix link for
Correlation Rule limitations.
When correlating groups of incidents under an existing Parent incident, use the Correlation Rules tab to
specify the Correlation Rule that defines the Parent Incident, the Child Incident, and the relationship
requirements that must be met before the incidents are correlated.
See "Correlation Rule Example" (on page 379) for a step-by-step example of how the Subinterface
Custom Correlation Rule provided by NNMi was created.
For information about each Correlation Rules tab:
To configure a Correlation Rule:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Correlation Rules tab.
3. From the Correlation Rules table toolbar, do one of the following:
n
To create a Correlation Rule, click the
n
To edit a Correlation Rule, click the
you want to edit, and continue.
n
To delete a Correlation Rule, click the
New icon, and continue.
Open icon in the row representing the Correlation Rule
Delete icon.
4. Create your Correlation Rule (see table).
5. Click
Save and Close to save your changes and return to the previous form.
Correlation Rule Basic Attributes
Attribute
Description
Name
Type a maximum of 64 characters. Alpha-numeric, spaces, and special characters (~ ! @ #
$ % ^ &amp; * ( ) _+) are allowed.
The name is used to identify the Correlation Rule and must be unique. Use a name that will
help you to remember the purpose of the Correlation Rule.
Author
Indicates who created or last modified the Correlation Rule.
See Author form for important information.
Caution: If the Author attribute value is HP Network Node Manager, any changes are at
risk of being overwritten in the future.
Click the
values or click
Enabled
Lookup icon and select
Quick Find to access the list of existing Author
New to create one.
If enabled, the NNMi Causal Engine uses the Correlation Rule when evaluating
incidents.
If
Page 355 of 1087
disabled, the Correlation Rule is ignored.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Parent
Incident
Specifies the incident configuration that should be used as the Parent Incident for the
Correlation Rule.
Note: If you want to create a rule to generate a Parent Incident configure a Causal Rule.
See "Configure a Causal Rule" (on page 382) for more information.
To specify a Parent Incident configuration:
1. Click the
Lookup icon, and do one of the following:
n
To specify a Parent Incident without making any changes to the Incident
configuration, select
Quick Find . In the Quick Find dialog, select the Incident of
interest.
n
To create a Parent Incident, select one of the following:
n
o
New Management Event Configuration
o
New Remote NNM Event Configuration
o
New SNMP Trap Configuration
To modify a Parent Incident, select
Open.
2. Optional. To create or modify a Parent Incident, enter or modify the attribute values for
the selected Incident configuration. See "Configuring Incidents" (on page 304) for
more information about the Incident Configuration form.
3. Click
Child
Incident
Save and Close to save your changes and return to the previous form.
Specifies the incident configuration that must match an incoming incident and that should
be correlated as the Child Incident for the Custom Correlation.
To specify a Child Incident configuration:
1. Click the
Lookup icon, and select
Quick Find.
2. In the Quick Find dialog, select the Incident of interest.
Correlation
Window
Duration
Description
The time window within which NNMi begins to correlate the incidents. Enter a number for
Days, Hours, Minutes, and Seconds.
Note the following:
l
If the Parent and Child incidents occur within the Correlation Window Duration
specified, NNMi begins to correlate the incidents as soon as they occur.
l
If you are relating multiple Custom Correlations, make sure the Correlation Window
Duration allows enough time for all of the Parent and Child incidents to be generated.
Use the description field to provide additional information that you would like to store about
the current incident configuration. This description applies only to the configuration entry.
Type a maximum of 2048 characters. Alpha-numeric, spaces, and special characters (~ ! @
# $ % ^ & * ( ) _+) are allowed.
Page 356 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Configure a Parent Incident Filter for a Correlation Rule
Note: See Help → Documentation Library → Release Notes, and locate the Support Matrix link for
Parent Incident Filter limitations.
Tip: The Parent Incident Filter is optional, but recommended. Use of a Parent Incident Filter improves NNMi
performance by reducing the set of incidents that NNMi processes.
When correlating groups of incidents under a Parent Incident, you can define the requirements for the
Parent Incident. The Parent Incident tab enables you to use the Filter Editor to define these requirements.
For example, you might want to specify that the Source Node of the Parent Incident be a specific node
Name pattern. See Valid Operators in the table that follows for examples of valid Parent Incident Filters.
When specifying the like or not like operator, use the syntax defined for Java regular expressions. See the
Pattern (Java Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Use the Filter Editor Buttons to insert Boolean Operators and to append, insert, and replace expressions in
the Filter String. Use the Drag and Drop feature to make changes to the placement of the expressions in
your Filter String. Click here for more information about using the Filter Editor for Custom Correlations:
l
You can use Custom Incident Attributes, attributes for an incident's Source Node or Source Object, or
both to define how matching incidents should be considered for the Correlation Rule. See Valid
Attributes for more information.
l
When specifying Attribute names and values, NNMi uses the type to determine a match. For example, if
the Attribute type is numeric, NNMi does a numeric comparison. If the Attribute type is textual, NNMi
does a lexographical string comparison. In all cases, when you use the like or not like operator, NNMi
uses a lexographical string comparison. Click here for more information about Attribute types:
n
ifIndex and ifSpeed are numeric Attributes.
n
Any Attribute name that begins wtih "is" (isSnmpInterface, isSnmpNode, isNnmSystemLocal)
represents a Boolean Attribute.
n
All other Attributes are textual.
l
Each set of expressions associated with a Boolean Operator (for example, AND) is treated as if it were
enclosed in parentheses and evaluated together.
l
View the expression displayed under Filter String to see the logic of the expression as it is created.
l
The AND and OR Boolean Operators must contain at least two expressions.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
Filter Editor Buttons and Drag and Drop Feature
Button or
Feature
Append
Page 357 of 1087
Description
Appends the current expression (Attribute, Operator,and Value) to the selected
expression already included in the filter string.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Button or
Feature
Description
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor
location within the Filter String.
Replace
Replaces the selected expression with the expression displayed Left or Right
Expression.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
Delete
Deletes the selected expression.
Note: If the Boolean Operator is selected, the Filter Editor deletes all expressions
associated with the Boolean Operator.
Drag and
Drop
You can drag any of the following items to a new location in the Filter String:
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
n
Click the item you want to move before dragging it to a new location.
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
n
If you are moving the selection down, NNMi places the item below the target
location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an
error message.
See "Configure a Correlation Rule" for a step-by-step example of how the Subinterface Correlation Rule
provided by NNMi was created.
To configure a Parent Incident Filter:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Correlation Rules tab.
3. From the Correlation Rules table toolbar, do one of the following:
Page 358 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
n
To create a Correlation Rule, click the
n
To edit a Correlation Rule, click the
want to edit, and continue.
n
To delete a Correlation Rule, click the
New icon, and continue.
Open icon in the row representing the configuration you
Delete icon.
4. Navigate to the Parent Incident Filter tab.
5. Create your Parent Incident Filter (see Filter Editor Components).
Filter Editor Components
Component
Description
Attribute
The Attribute on which NNMi searches. See Valid Attributes below for a description
of valid Attributes.
Operator
Use this Operator to establish the relationship between the Attribute and Expression.
See Valid Operators in the table below for the description of each valid Operator.
Expression
Use the Expression to complete the criteria for the Parent Incident configuration. See
Valid Expressions below for a description of the components that you might include
in your Expression.
6. Click
Save and Close to save your changes and return to the previous form.
Valid Attributes
Attribute
Description
Attribute
The Attribute on which NNMi searches. Valid attributes other than Source Node attributes
depend on the Incident's Source Object. NNMi checks the Source Node as well as the
Source Object for any Capability value.
Note the following when specifying Attributes:
l
Boolean Attributes begin with "is" and must contain the value true or false.
l
Use the following syntax to specify a Custom Incident Attribute (CIA):
valueOfCia(<CIA_Name>)
Note: Check the appropriate Incident form for any valid CIA Names provided by NNMi.
For example: ${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
l
When specifying CIA_Name or CA_Name you can use the asterisk (*) as a wildcard
character to specify one or more characters and a question mark (?) to specify a single
character.
l
If you use attributes that are valid for the Source Node, NNMi uses the Source Node when
comparing values. If you use attributes that are valid for the Source Object, NNMi uses the
Source Object when comparing values. You cannot use attributes that are valid for the
Source Node and Source Object in the same filter.
Possible Source Object choices are as follows:
l
Card [click here for a list of attribute values]
Unique Keys from the Card Form: Capabilities Tab:
n
Page 359 of 1087
capability (Unique Key of the Capability)
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
l
Interface [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for an Interface:
valueOfInterfaceCa(<CA_Name>)
For example: ${child.valueOfInterfaceCA(Role)} =
WAN Connection
Values from the Basics Attributes listed on the Interface Form:
n
hostedOn (Hosted On Node)
Note: You must use the full DNS name for the hostedOn value.
Values from the Interface Form: General Tab:
n
ifName (name configured for the interface)
n
ifAlias (alias configured for the interface)
n
ifDescr (description configured for the interface)
n
ifIndex (index assigned to the interface)
n
ifSpeed (speed configured for the interface)
Note: When entering the value for ifSpeed, use the actual numeric value for the
interface speed. For example, use 10000000 for ifSpeed 10 Mbps.
Addresses from the Interface Form: IP Addresses Tab:
n
ipAddress (IP Address associated with the interface)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <=.
Unique Keys from the Interface Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the parent Node Form:
n
isSnmpInterface (Agent Enabled)
Values from the parent Node Form: General Tab:
n
sysOidInterface (System Object ID)
Values from the Basics Attributes on the associated Device Profile Form:
l
n
devVendorInterface (Device Vendor)
n
devFamilyInterface (Device Family)
IP Address [click here for a list of attribute values]
Unique Keys from the IP Address Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Node [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for a Node:
valueOfNodeCa(<CA_Name>)
Page 360 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
For example: ${valueOfNodeCA(Location)} = USA
Values from the Basics Attributes on the Node Form:
n
hostname (Hostname, case-sensitive)
n
mgmtIPAddress (Management Address)
n
isSnmpNode (Agent Enabled)
n
isNnmSystemLocal (NNMi Management Server)
Values from the Node Form: General Tab:
n
sysName (System Name)
n
sysContact (System Contact)
n
sysLocation (System Location)
n
sysOidNode (System Object ID)
Addresses from the Node Form: IP Addresses Tab:
n
hostedIPAddress (Address)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <= .
Unique Keys from the Node Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the associated Device Profile Form:
n
devVendorNode (Device Vendor)
n
devFamillyNode (Device Family)
Values from the associated entry on the Regional Manager Form: Connection Tab:
n
nnmSystemName (Hostname, case-sensitive)
(NNMi Advanced) If the Global Network Management feature is enabled, this attribute
value identifies a Regional Manager (NNMi management server).
Page 361 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute Description
Valid Operator Values
Operator
Description
=
Finds all values equal to the value specified.
Click here for examples.
Match any incident with a CIA value of 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
Match any incident with the Source Object's Capability equal to
com.hp.nnm.capability.card.fru
$(capability) = com.hp.nnm.capability.card.fru
!=
Finds all values not equal to the value specified.
Click here for an example.
Match any incident with Device Vendor for the interface (Source Object) not equal to Cisco:
${devVendorInterface} != Cisco
<
Finds all values less than the value specified.
Click here for an example.
Match any incident with a CIA value of less than 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} < 5
<=
Finds all values less than or equal to the value specified.
Click here for examples.
Match any incident with a CIA value of less than or equal to 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} <= 5
>
Finds all values greater than the value specified.
Click here for an example.
Match any incident with a CIA value of greater than 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} > 5
>=
Finds all values greater than or equal to the value specified.
Click here for an example.
Match any incident with a Source Object's (interface speed) ifSpeed value of 10Mbps:
${ifSpeed} >= 10000000
is not
null
Finds all non-blank values.
Click here for an example.
Page 362 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
Match any incident with a Source Object's (interface name) ifName attribute that contains a
value:
${ifName} is not null
is null
Finds all blank values.
Click here for an example.
Match any incident with a Source Object's (interface name) ifName attribute that does not
contain a value:
${ifName} is null
like
Finds matches using the syntax defined for Java regular expressions. See the Pattern (Java
Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Object's (interface description) ifDesc attribute that includes
Serial followed by one or more digits:
${ifDesc} like Serial\d+
Match any incident with a Source Object's (interface alias) ifAlias attribute that contains
EtherChannel (for example, PAgPEtherChannel Group 1).
Note: The . (period) indicates any alphanumeric character.
${ifAlias} like .*EtherChannel.*
Match any incident with a CIA attribute value of Chassis Fan Tray followed by a digit and
Object Identifier (OID) of .1.3.6.1.4.1.9.9.13.1.4.1.3
Note: To include literal strings in the value, enclose the string value in \Q<literal_value>\E as
shown in the following example.
${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.3\E)} like Chassis Fan Tray \d
Page 363 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
not like
Finds all matches that do not have the values specified using the syntax defined for Java
regular expressions. See the Pattern (Java Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Object's (interface name) ifName value that does not
include rtr:
${ifName} not like .*rtr.*
Valid Expressions
Attribute
Description
Expression
The value or pattern for which you want NNMi to search.
Note the following:
l
The expression can include a valid Attribute.
l
The value or pattern you want to match is case sensitive.
l
When entering the value for ifSpeed, use the actual numeric value for the interface
speed. For example, use 10000000 for ifSpeed 10 Mbps.
Configure a Child Incident Filter for a Correlation Rule
Note: See Help → Documentation Library → Release Notes, and locate the Support Matrix link for Child
Incident Filter limitations.
Tip: The Child Incident Filter is optional, but recommended. Use of a Child Incident Filter improves NNMi
performance by reducing the set of incidents that NNMi processes.
When correlating groups of incidents under a Parent incident, you must specify the requirements for the
Child Incident. The Child Incident tab enables you to use the Filter Editor to define these requirements. For
example, you might want to specify that the Source Node of the Child Incident be a specific Node Name
pattern. See Valid Operators in the table that follows for examples of valid Child Incident Filters.
Use the Filter Editor Buttons to insert Boolean Operators and to append, insert, and replace expressions in
the Filter String. Use the Drag and Drop feature to make changes to the placement of the expressions in
your Filter String. Click here for more information about using the Filter Editor for Custom Correlations:
l
You can use Custom Incident Attributes, attributes for an incident's Source Node or Source Object, or
both to define how matching incidents should be considered for the Correlation Rule. See Valid
Attributes for more information.
l
When specifying Attribute names and values, NNMi uses the type to determine a match. For example, if
the Attribute type is numeric, NNMi does a numeric comparison. If the Attribute type is textual, NNMi
does a lexographical string comparison. In all cases, when you use the like or not like operator, NNMi
Page 364 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
uses a lexographical string comparison. Click here for more information about Attribute types:
n
ifIndex and ifSpeed are numeric Attributes.
n
Any Attribute name that begins wtih "is" (isSnmpInterface, isSnmpNode, isNnmSystemLocal)
represents a Boolean Attribute.
n
All other Attributes are textual.
l
Each set of expressions associated with a Boolean Operator (for example, AND) is treated as if it were
enclosed in parentheses and evaluated together.
l
View the expression displayed under Filter String to see the logic of the expression as it is created.
l
The AND and OR Boolean Operators must contain at least two expressions.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
Filter Editor Buttons and Drag and Drop Feature
Button or
Feature
Description
Append
Appends the current expression (Attribute, Operator,and Value) to the selected
expression already included in the filter string.
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor
location within the Filter String.
Replace
Replaces the selected expression with the expression displayed Left or Right
Expression.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
Delete
Deletes the selected expression.
Note: If the Boolean Operator is selected, the Filter Editor deletes all expressions
associated with the Boolean Operator.
Drag and
Drop
You can drag any of the following items to a new location in the Filter String:
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
n
Page 365 of 1087
Click the item you want to move before dragging it to a new location.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Button or
Feature
Description
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
n
If you are moving the selection down, NNMi places the item below the target
location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an
error message.
See "Correlation Rule Example" (on page 379) for a step-by-step example of how the Subinterface
Correlation Rule provided by NNMi was created.
To configure a Child Incident Filter:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Correlation Rules tab.
3. From the Correlation Rules table toolbar, do one of the following:
n
To create a Correlation Rule, click the
n
To edit a Correlation Rule, click the
you want to edit, and continue.
n
To delete a Correlation Rule, click the
New icon, and continue.
Open icon in the row representing the Correlation Rule
Delete icon.
4. Navigate to the Child Incident Filter tab.
5. Create your Child Incident Filter (see the Filter Editor Components below).
Filter Editor Components
Component
Description
Attribute
The Attribute on which NNMi searches. See Valid Attributes below for a description
of valid Attributes.
Operator
Use this Operator to establish the relationship between the Attribute and Expression.
See Valid Operators in the table below for the description of each valid Operator.
Note: When specifying the like or not like operator, you must use the syntax defined
for Java regular expressions. See the Pattern (Java Platform SE6) API
documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more
information.
Expression
6. Click
Use the Expression to complete the criteria for the Child Incident configurations. See
Valid Expressions below for a description of the components that you might include
in your Expression.
Save and Close to save your changes and return to the previous form.
Page 366 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Valid Attributes
Attribute
Description
Attribute
The Attribute on which NNMi searches. Valid attributes other than Source Node attributes
depend on the Incident's Source Object. NNMi checks the Source Node as well as the
Source Object for any Capability value.
Note the following when specifying Attributes:
l
Boolean Attributes begin with "is" and must contain the value true or false.
l
Use the following syntax to specify a Custom Incident Attribute (CIA):
valueOfCia(<CIA_Name>)
Note: Check the appropriate Incident form for any valid CIA Names provided by NNMi.
For example: ${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
l
When specifying CIA_Name or CA_Name you can use the asterisk (*) as a wildcard
character to specify one or more characters and a question mark (?) to specify a single
character.
l
If you use attributes that are valid for the Source Node, NNMi uses the Source Node when
comparing values. If you use attributes that are valid for the Source Object, NNMi uses the
Source Object when comparing values. You cannot use attributes that are valid for the
Source Node and Source Object in the same filter.
Possible Source Object choices are as follows:
l
Card [click here for a list of attribute values]
Unique Keys from the Card Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Interface [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for an Interface:
valueOfInterfaceCa(<CA_Name>)
For example: ${child.valueOfInterfaceCA(Role)} =
WAN Connection
Values from the Basics Attributes listed on the Interface Form:
n
hostedOn (Hosted On Node)
Note: You must use the full DNS name for the hostedOn value.
Values from the Interface Form: General Tab:
n
ifName (name configured for the interface)
n
ifAlias (alias configured for the interface)
n
ifDescr (description configured for the interface)
n
ifIndex (index assigned to the interface)
n
ifSpeed (speed configured for the interface)
Note: When entering the value for ifSpeed, use the actual numeric value for the
interface speed. For example, use 10000000 for ifSpeed 10 Mbps.
Addresses from the Interface Form: IP Addresses Tab:
Page 367 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
n
ipAddress (IP Address associated with the interface)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <=.
Unique Keys from the Interface Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the parent Node Form:
n
isSnmpInterface (Agent Enabled)
Values from the parent Node Form: General Tab:
n
sysOidInterface (System Object ID)
Values from the Basics Attributes on the associated Device Profile Form:
l
n
devVendorInterface (Device Vendor)
n
devFamilyInterface (Device Family)
IP Address [click here for a list of attribute values]
Unique Keys from the IP Address Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Node [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for a Node:
valueOfNodeCa(<CA_Name>)
For example: ${valueOfNodeCA(Location)} = USA
Values from the Basics Attributes on the Node Form:
n
hostname (Hostname, case-sensitive)
n
mgmtIPAddress (Management Address)
n
isSnmpNode (Agent Enabled)
n
isNnmSystemLocal (NNMi Management Server)
Values from the Node Form: General Tab:
n
sysName (System Name)
n
sysContact (System Contact)
n
sysLocation (System Location)
n
sysOidNode (System Object ID)
Addresses from the Node Form: IP Addresses Tab:
n
hostedIPAddress (Address)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <= .
Page 368 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Unique Keys from the Node Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the associated Device Profile Form:
n
devVendorNode (Device Vendor)
n
devFamillyNode (Device Family)
Values from the associated entry on the Regional Manager Form: Connection Tab:
n
nnmSystemName (Hostname, case-sensitive)
(NNMi Advanced) If the Global Network Management feature is enabled, this attribute
value identifies a Regional Manager (NNMi management server).
Page 369 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute Description
Valid Operator Values
Operator
Description
=
Finds all values equal to the value specified.
Click here for examples.
Match any incident with a CIA value of 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
Match any incident with the Source Object's Capability equal to
com.hp.nnm.capability.card.fru
$(capability) = com.hp.nnm.capability.card.fru
!=
Finds all values not equal to the value specified.
Click here for an example.
Match any incident with Device Vendor for the interface (Source Object) not equal to Cisco:
${devVendorInterface} != Cisco
<
Finds all values less than the value specified.
Click here for an example.
Match any incident with a CIA value of less than 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} < 5
<=
Finds all values less than or equal to the value specified.
Click here for examples.
Match any incident with a CIA value of less than or equal to 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} <= 5
>
Finds all values greater than the value specified.
Click here for an example.
Match any incident with a CIA value of greater than 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} > 5
>=
Finds all values greater than or equal to the value specified.
Click here for an example.
Match any incident with a Source Object's (interface speed) ifSpeed value of 10Mbps:
${ifSpeed} >= 10000000
is not
null
Finds all non-blank values.
Click here for an example.
Page 370 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
Match any incident with a Source Object's (interface name) ifName attribute that contains a
value:
${ifName} is not null
is null
Finds all blank values.
Click here for an example.
Match any incident with a Source Object's (interface name) ifName attribute that does not
contain a value:
${ifName} is null
like
Finds matches using the syntax defined for Java regular expressions. See the Pattern (Java
Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Object's (interface description) ifDesc attribute that includes
Serial followed by one or more digits:
${ifDesc} like Serial\d+
Match any incident with a Source Object's (interface alias) ifAlias attribute that contains
EtherChannel (for example, PAgPEtherChannel Group 1).
Note: The . (period) indicates any alphanumeric character.
${ifAlias} like .*EtherChannel.*
Match any incident with a CIA attribute value of Chassis Fan Tray followed by a digit and
Object Identifier (OID) of .1.3.6.1.4.1.9.9.13.1.4.1.3
Note: To include literal strings in the value, enclose the string value in \Q<literal_value>\E as
shown in the following example.
${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.3\E)} like Chassis Fan Tray \d
Page 371 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
not like
Finds all matches that do not have the values specified using the syntax defined for Java
regular expressions. See the Pattern (Java Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Object's (interface name) ifName value that does not
include rtr:
${ifName} not like .*rtr.*
Valid Expressions
Attribute
Description
Expression
The value or pattern for which you want NNMi to search.
Note the following:
l
The expression can include a valid Attribute.
l
The value or pattern you want to match is case sensitive.
l
When entering the value for ifSpeed, use the actual numeric value for the interface
speed. For example, use 10000000 for ifSpeed 10 Mbps.
Configure a Correlation Filter
Note: See Help → Documentation Library → Release Notes, and locate the Support Matrix link for
Correlation Filter limitations.
When correlating groups of incidents under a Parent incident, you must specify the Correlation Filter that
defines the relationship requirements that must be met before the incidents are correlated. The Correlation
Filter tab enables you to use the Filter Editor to define these relationship requirements. See Valid
Operators in the table that follows for examples of valid Correlation Filters.
Use the Filter Editor Buttons to insert Boolean Operators and to append, insert, and replace expressions in
the Filter String. Use the Drag and Drop feature to make changes to the placement of the expressions in
your Filter String. Click here for more information about using the Filter Editor for Custom Correlations:
l
You can use Custom Incident Attributes, attributes for an incident's Source Node or Source Object, or
both to define how matching incidents should be considered for the Correlation Rule. See Valid
Attributes for more information.
l
When specifying Attribute names and values, NNMi uses the type to determine a match. For example, if
the Attribute type is numeric, NNMi does a numeric comparison. If the Attribute type is textual, NNMi
does a lexographical string comparison. In all cases, when you use the like or not like operator, NNMi
uses a lexographical string comparison. Click here for more information about Attribute types:
n
ifIndex and ifSpeed are numeric Attributes.
Page 372 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
n
Any Attribute name that begins wtih "is" (isSnmpInterface, isSnmpNode, isNnmSystemLocal)
represents a Boolean Attribute.
n
All other Attributes are textual.
l
Each set of expressions associated with a Boolean Operator (for example, AND) is treated as if it were
enclosed in parentheses and evaluated together.
l
View the expression displayed under Filter String to see the logic of the expression as it is created.
l
The AND and OR Boolean Operators must contain at least two expressions.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
Filter Editor Buttons and Drag and Drop Feature
Button or
Feature
Description
Append
Appends the current expression (Attribute, Operator,and Value) to the selected
expression already included in the filter string.
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor
location within the Filter String.
Replace
Replaces the selected expression with the expression displayed Left or Right
Expression.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
Delete
Deletes the selected expression.
Note: If the Boolean Operator is selected, the Filter Editor deletes all expressions
associated with the Boolean Operator.
Drag and
Drop
You can drag any of the following items to a new location in the Filter String:
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
Page 373 of 1087
n
Click the item you want to move before dragging it to a new location.
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Button or
Feature
Description
n
If you are moving the selection down, NNMi places the item below the target
location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an
error message.
See "Correlation Rule Example" (on page 379) for a step-by-step example of how the Subinterface
Custom Correlation Rule provided by NNMi was created.
To configure a Correlation Filter:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Correlation Rules tab.
3. From the Correlation Rules table toolbar, do one of the following:
n
To create a Correlation Rule, click the
n
To edit a Correlation Rule, click the
you want to edit, and continue.
n
To delete a Correlation Rule, click the
New icon, and continue.
Open icon in the row representing the Correlation Rule
Delete icon.
4. Navigate to the Correlation Filter tab.
5. Create your Correlation Filter (see Filter Editor Components).
Filter Editor Components
Component
Description
Attribute
The Attribute on which NNMi searches. See Valid Attributes below for a description
of valid Attributes.
Operator
Use this Operator to establish the relationship between the Attribute and Expression.
See Valid Operators in the table below for the description of each valid Operator.
Expression
Use the Expression to complete the criteria for the required relationship between the
parent and child incident configurations. See Valid Expressions below for a
description of the components that you might include in your Right Expression.
6. Click
Save and Close to save your changes and return to the previous form.
Valid Attributes
Attribute
Description
Attribute
The Attribute on which NNMi searches. Valid attributes other than Source Node attributes
depend on the Incident's Source Object. NNMi checks the Source Node as well as the
Source Object for any Capability value.
Note the following when specifying Attributes:
Page 374 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
l
Boolean Attributes begin with "is" and must contain the value true or false.
l
Use the following syntax to specify a Custom Incident Attribute (CIA):
valueOfCia(<CIA_Name>)
Note: Check the appropriate Incident form for any valid CIA Names provided by NNMi.
For example: ${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
l
When specifying CIA_Name or CA_Name you can use the asterisk (*) as a wildcard
character to specify one or more characters and a question mark (?) to specify a single
character.
l
If you use attributes that are valid for the Source Node, NNMi uses the Source Node when
comparing values. If you use attributes that are valid for the Source Object, NNMi uses the
Source Object when comparing values. You cannot use attributes that are valid for the
Source Node and Source Object in the same filter.
Possible Source Object choices are as follows:
l
Card [click here for a list of attribute values]
Unique Keys from the Card Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Interface [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for an Interface:
valueOfInterfaceCa(<CA_Name>)
For example: ${child.valueOfInterfaceCA(Role)} =
WAN Connection
Values from the Basics Attributes listed on the Interface Form:
n
hostedOn (Hosted On Node)
Note: You must use the full DNS name for the hostedOn value.
Values from the Interface Form: General Tab:
n
ifName (name configured for the interface)
n
ifAlias (alias configured for the interface)
n
ifDescr (description configured for the interface)
n
ifIndex (index assigned to the interface)
n
ifSpeed (speed configured for the interface)
Note: When entering the value for ifSpeed, use the actual numeric value for the
interface speed. For example, use 10000000 for ifSpeed 10 Mbps.
Addresses from the Interface Form: IP Addresses Tab:
n
ipAddress (IP Address associated with the interface)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <=.
Unique Keys from the Interface Form: Capabilities Tab:
Page 375 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the parent Node Form:
n
isSnmpInterface (Agent Enabled)
Values from the parent Node Form: General Tab:
n
sysOidInterface (System Object ID)
Values from the Basics Attributes on the associated Device Profile Form:
l
n
devVendorInterface (Device Vendor)
n
devFamilyInterface (Device Family)
IP Address [click here for a list of attribute values]
Unique Keys from the IP Address Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Node [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for a Node:
valueOfNodeCa(<CA_Name>)
For example: ${valueOfNodeCA(Location)} = USA
Values from the Basics Attributes on the Node Form:
n
hostname (Hostname, case-sensitive)
n
mgmtIPAddress (Management Address)
n
isSnmpNode (Agent Enabled)
n
isNnmSystemLocal (NNMi Management Server)
Values from the Node Form: General Tab:
n
sysName (System Name)
n
sysContact (System Contact)
n
sysLocation (System Location)
n
sysOidNode (System Object ID)
Addresses from the Node Form: IP Addresses Tab:
n
hostedIPAddress (Address)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <= .
Unique Keys from the Node Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the associated Device Profile Form:
n
devVendorNode (Device Vendor)
Page 376 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
n
devFamillyNode (Device Family)
Values from the associated entry on the Regional Manager Form: Connection Tab:
n
nnmSystemName (Hostname, case-sensitive)
(NNMi Advanced) If the Global Network Management feature is enabled, this attribute
value identifies a Regional Manager (NNMi management server).
Page 377 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Valid Operators
Attribute Description
Operator Description
=
Finds all values equal to the value specified.
Click here for an example.
Correlate the incidents if the hostedOn value for the Source Object of the Child Incident is
equal to the hostedOn value for the Source Object in the Parent Incident.
${child.hostedOn} = ${parent.hostedOn}
!=
Finds all values not equal to the value specified.
Click here for an example.
Correlate the incidents if the hostedOn value for the Source Object of the Child Incident is
not equal to the hostedOn value for the Source Object in the Parent Incident.
${child.hostedOn} != ${parent.hostedOn}
<
Finds all values less than the value specified.
<=
Finds all values less than or equal to the value specified.
>
Finds all values greater than the value specified.
>=
Finds all values greater than or equal to the value specified.
is not
null
Finds all non-blank values.
is null
Finds all blank values.
like
Finds matches using the syntax defined for Java regular expressions. See the Pattern (Java
Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
not like
Finds all matches that do not have the values specified using the syntax defined for Java
regular expressions. See the Pattern (Java Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
Page 378 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Valid Expressions
Attribute
Description
Expression
The value or pattern for which you want NNMi to search.
Note the following:
l
The expression can include a valid Attribute.
l
The value or pattern you want to match is case sensitive.
l
When entering the value for ifSpeed, use the actual numeric value for the interface
speed. For example, use 10000000 for ifSpeed 10 Mbps.
Correlation Rule Example
Tip: Use these steps as a guideline for creating your own Correlation Rules.
This example uses the Subinterface Correlation Rule to describe the steps for creating a Correlation Rule.
The Subinterface Correlation Rule specifies that Interface Down incidents that occur for subinterfaces
should be correlated under the Interface Down incident generated for the main interface. Click here for
more information about Custom Correlations.
The NNMi Custom Correlation feature enables you to correlate groups of incidents under a Parent
Incident. This feature is useful when you want to define a relationship between a number of incidents
potentially from different network objects that form a logical set to identify a problem. The set of correlations
is considered complete if all of the incidents arrive within a specified time window. You can correlate
incidents under an existing Incident Configuration (Correlation Rule) or create a new Incident
Configuration (Causal Rule).
This example uses an existing Incident Configuration as the Parent Incident. See "Causal Rule Example"
(on page 406) for an example that generates a new Incident Configuration as the Parent Incident.
To configure the Subinterface Correlation Rule Basics information:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Correlation Rules tab.
3. From the Correlation Rules table toolbar, click the
New icon.
4. In the Name attribute, enter a unique name that will help you to identify the Correlation Rule. In this
example, the Correlation Rule Name is Subinterface.
5. In the Author attribute, enter a name that identifies the person who is creating the Correlation Rule.
In this example, HP Network Node Manager is the Author name to identify this Correlation Rule as
one that NNMi provides.
6. Make sure Enabled
is checked to indicate the NNMi Causal Engine should use this Correlation
Rule when evaluating incidents.
7. To use an existing Parent Incident, do the following:
a. In the Parent Incident Lookup Field, select
incident configurations.
b. Click the
Page 379 of 1087
Quick Find to select from the list of existing
Select This Item icon that precedes the incident configuration that must match an
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
incoming incident and that should be correlated as the Parent Incident for the Custom
Correlation.
In the Subinterface Correlation Rule, the InterfaceDown incident configuration was selected
as the Parent Incident.
8. Select the Incident Configuration that must match an incoming incident and that should be correlated
as the Child Incident for the Custom Correlation.
In the Subinterface Correlation Rule, the InterfaceDown incident configuration was also selected as
the Child Incident.
9. In the Correlation Duration Window attribute, enter the time limit (in days, hours, minutes, and
seconds) that must be reached before the incoming incident are correlated. The Subinterface
Correlation Rule specifies a Correlation Window Duration of 6 minutes.
10. Use the Description attribute to provide additional information that you would like to store about the
current incident configuration. This description applies only to the configuration entry.
The Subinterface Correlation Rule includes the following description: Correlates sub-interfaces
down incidents under the main interface down.
To configure the Parent Incident Filter:
1. In the Correlation Rule form, navigate to the Parent Incident Filter tab.
2. The following Parent Incident Filter specifies that the Correlation Rule applies only to Cisco devices:
${devVendorInterface} = Cisco
3. The following Parent Incident Filter specifies that the ifDesc value must contain the string Serial
followed by one or more digits and then a forward slash, followed by zero or more digits:
${ifDesc}like Serial\d+/*\d*
4. As shown in the following Filter String, the Parent Incident Filters use the Boolean operator AND so
that both criteria must be met for the Incident to be selected as a Parent:
{${devVendorInterface} = Cisco AND ${ifDesc} like Serial\d+/*\d*)
To create this Parent Incident Filter, in the Filter Editor:
a. Click And.
b. In the Attribute field, enter ${devVendorInterface}.
c. In the Operator field, select = from the drop-down menu.
d. In the Expression field, enter Cisco.
e. Click Append.
f. In the Attribute field, enter ${ifDesc}.
g. In the Operator field, select like from the drop-down menu.
h. In the Expression field, enter Serial\d+/*\d*.
i. Click Add.
To configure the Child Incident Filter:
1. In the Correlation Rule form, navigate to the Child Incident Filter tab.
2. The following Child Incident Filter specifies that the Correlation Rule applies only to Cisco devices:
Page 380 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
${devVendorInterface} = Cisco
3. The following Child Incident Filter specifies that the ifDesc value must contain the following sequence
of values:
The string Serial followed by one or more digits, then a forward slash, followed by zero or more
digits, and then a period followed by one or more digits:
${ifDesc}like Serial\d+/*\d*
4. As shown in the following Filter String, the Child Incident Filters use the Boolean operator AND so
that both criteria must be met for the Incident to be selected as a Child:
{${devVendorInterface} = Cisco AND ${ifDesc} like Serial\d+/*\d*)
To create this Parent Incident Filter, in the Filter Editor:
a. Click And.
b. In the Attribute field, enter ${devVendorInterface}.
c. In the Operator field, select = from the drop-down menu.
d. In the Expression field, enter Cisco.
e. Click Append.
f. In the Attribute field, enter ${ifDesc}.
g. In the Operator field, select like from the drop-down menu.
h. In the Expression field, enter Serial\d+/*\d*.
i. Click Append.
To configure the Correlation Filter:
Note: When specifying a Correlation Filter, you must specify whether the attribute is from a Child Incident
or Parent Incident using the following syntax: ${child.<attribute_name>} or
${parent.<attribute_name>}.
1. In the Correlation Rule form, navigate to the Correlation Filter tab.
2. To ensure that the Interface Down incidents are generated for the same node, the Subinterface
Correlation Rules uses hostedOn as the attribute for both the Child and Parent Incidents as shown in
the following example filter:
${child.hostedOn}= ${parent.hostedOn}
To ensure that the Interfaces are subinterfaces for the main interface, the filter also matches the
ifDesc values:
${child.ifDesc}like ${parent.ifDesc}.*
As shown in the following Filter String, the Correlation Filter uses the Boolean operator AND so that
both criteria must be met for the Incidents to be correlated:
${child.hostedOn} = ${parent.hostedOn}AND ${child.ifDesc} like
${parent.ifDesc}.*
To create the Correlation Rule filter:
a. Click And.
b. In the Attribute field, enter ${child.hostedOn}.
Page 381 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
c. In the Operator field, select = from the drop-down menu.
d. In the Expression field, enter ${parent.hostedOn}.
e. Click Append.
f. In the Attribute field, enter ${child.ifDesc}.
g. In the Operator field, select like from the drop-down menu.
h. In the Expression field, enter ${parent.ifDesc}.*.
i. Click Append.
3. Click
Save and Close to save your changes and return to the previous form.
Configure a Causal Rule
Tip: Configure a Causal Rule when you want to cause NNMi to generate a Parent Incident and you want to
correlate one or more Child Incident Configurations under the Parent Incident that you cause to be
generated.
Note: See Help → Documentation Library → Release Notes, and locate the Support Matrix link for
Causal Rule limitations.
When correlating groups of incidents under a Parent incident, use the Causal Rules tab to specify the
following.
l
Parent Incident Configuration to be generated
l
One or more Child Incident Configurations to be correlated with the generated Parent Incident
l
Filters that NNMi should use when selecting the Child Incident instances for correlation
l
Source Object and Source Node Filter to be used to determine the Source Node and Source Object for
the Parent Incident that is generated
l
The time window that must be met before NNMi correlates the incidents
For information about each Causal Rules tab:
To configure a Causal Rule:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Causal Rules tab.
3. From the Causal Rules table toolbar, do one of the following:
n
To create a Causal Rule, click the
n
To edit a Causal Rule, click the
to edit, and continue.
n
To delete a Causal Rule, click the
New icon, and continue.
Open icon in the row representing the Causal Rule you want
Delete icon.
4. Create your Causal Rule (see table).
5. Click
Save and Close to save your changes and return to the previous form.
Page 382 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Cause Rule Basic Attributes
Attribute
Description
Name
Type a maximum of 64 characters. Alpha-numeric, spaces, and special characters (~ ! @
# $ % ^ &amp; * ( ) _+) are allowed.
The name is used to identify the Causal Rule and must be unique. Use a name that will
help you to remember the purpose of the Causal Rule.
Author
Indicates who created or last modified the Causal Rule.
See Author form for important information.
Caution: If the Author attribute value is HP Network Node Manager, any changes are at
risk of being overwritten in the future.
Click the
Lookup icon and select
values or click
Enabled
If
enabled, the NNMi Causal Engine uses the Causal Rule when evaluating incidents.
If
Parent
Incident
Quick Find to access the list of existing Author
New to create one.
disabled, the Causal Rule is ignored.
Specifies the incident configuration that should be generated as the Parent Incident for the
Causal Rule.
To specify a Parent Incident configuration:
1. Click the
Lookup icon, and do one of the following:
n
To specify a Parent Incident without making any changes to the Incident
configuration, select
Quick Find . In the Quick Find dialog, select the Incident
of interest.
n
To create a Parent Incident, select one of the following:
n
o
New Management Event Configuration
o
New Remote NNM Event Configuration
o
New SNMP Trap Configuration
To modify a Parent Incident, select
Open.
2. Optional. To create or modify a Parent Incident, enter or modify the attribute values
for the selected Incident configuration. See "Configuring Incidents" (on page 304) for
more information about the Incident Configuration form.
3. Click
Correlation
Nature
Save and Close to save your changes and return to the previous form.
Select the Correlation Nature that you want to assign to the Parent Incident that is
generated.
Note: The Child Incident will have the Correlation Nature of Secondary Root Cause.
Common
Child
Incident
Attribute
Specifies the Incident Attribute that all Child Incidents must have in common for the
incident instance to be correlated under the Parent Incident defined for the Causal Rule.
Note: You cannot specify $(capability) as a Common Child Incident Attribute.
Page 383 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Correlation
Window
Duration
The time window that must be met before NNMi correlates the incidents. Enter a number
for Days, Hours, Minutes, and Seconds.
Description
Note the following:
l
NNMi waits until the Correlation Window Duration has passed before generating the
Parent Incident and correlating its Child Incidents.
l
If you are relating multiple Custom Correlations, make sure the Correlation Window
Duration allows enough time for all of the Parent and Child incidents to be generated.
Use the description field to provide additional information that you would like to store
about the current incident configuration. This description applies only to the configuration
entry.
Type a maximum of 2048 characters. Alpha-numeric, spaces, and special characters (~ !
@ # $ % ^ & * ( ) _+) are allowed.
Configure a Child Incident for a Causal Rule
The Child Incident tab enables you to specify which Child Incidents should be considered for correlation
according to the Causal Rule you are configuring.
For information about each Causal Rules tab:
For information about each Child Incident tab:
To configure a Child Incident for a Causal Rule:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Causal Rules tab.
3. From the Causal Rules table toolbar, do one of the following:
n
To create a Causal Rule, click the
n
To edit a Causal Rule, click the
to edit, and continue.
n
To delete a Causal Rule, click the
New icon, and continue.
Open icon in the row representing the Causal Rule you want
Delete icon.
4. Create your Causal Rule. (See "Configure a Causal Rule" (on page 382).)
5. Create your Child Incident Configuration (see table).
6. Optional. Configure a Child Incident Filter. (See "Configure a Child Incident Filter for a Causal Rule"
(on page 386).)
7. Optional. Configure a Source Object Filter. (See "Configure a Source Object Filter for a Causal Rule"
(on page 393).)
8. Optional. Configure a Source Node Filter. (See "Configure a Source Node Filter for a Causal Rule"
(on page 400).)
9. Click
Save and Close to save your changes and return to the previous form.
Page 384 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Causal Rule Basic Attributes
Attribute
Description
Name
Type a maximum of 64 characters. Alpha-numeric, spaces, and special characters (~ !
@ # $ % ^ &amp; * ( ) _+) are allowed.
The name is used to identify the Child Incident Configuration and must be unique
within each Causal Rule. Use a name that will help you to remember the purpose of
the Child Incident Configuration.
Child Incident
Specifies the incident configuration that should be used as the Child Incident when
evaluating the Causal Rule.
To specify a Child Incident configuration:
1. Click the
Lookup icon, and do one of the following:
n
To specify a Child Incident without making any changes to the incident
configuration, select
Quick Find . In the Quick Find dialog, select the
Incident of interest.
n
To create a Child Incident, select one of the following:
n
o
New Management Event Configuration
o
New Remote NNM Event Configuration
o
New SNMP Trap Configuration
To modify a Child Incident, select
Open.
2. Optional. To create or modify a Child Incident, enter or modify the attribute
values for the selected Incident configuration. See "Configuring Incidents" (on
page 304) for more information about the Incident Configuration form.
3. Click
Save and Close to save your changes and return to the previous form.
Forward Child
Enter a comma-delimited list of the Custom Incident Attributes you want to appear with
Custom Incident the generated Parent Incident. NNMi forwards these values from the Child Incidents
Attributes
that you configure for the Causal Rule.
Optional Child
Incident
If enabled, the NNMi Causal Engine generates the Parent Incident whether this
Child Incident occurs.
If
disabled, the NNMi Causal Engine only generates the Parent Incident if this
Child Incident occurs.
Use Child
Incident's
Source Object
for Parent
If enabled, indicates you want NNMi to use the Source Object of the Child Incident
as the Source Object for the Parent Incident.
Note: If you enable this option, NNMi ignores any Source Object Filter you configured.
If
disabled, indicates you want NNMi to use the Source Object Filter configuration
to determine the Parent Incident's Source Node. See "Configure a Source Object Filter
for a Causal Rule" (on page 393) for more information.
If you do not specify the Source Object to use for the Parent Incident, NNMi uses the
Source Object of the first Child Incident that occurs.
Page 385 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Use Child
Incident's
Source Node
for Parent
If enabled, indicates you want NNMi to use the Source Node of the Child Incident
as the Source Node for the Parent Incident.
Note: If you enable this option, NNMi ignores any Source Node Filter you configured.
If
disabled, indicates you want NNMi to use the Source Node Filter configuration to
determine the Parent Incident's Source Node. See "Configure a Source Node Filter for
a Causal Rule" (on page 400) for more information.
If you do not specify the Source Node to use for the Parent Incident, NNMi uses the
Source Node of the first Child Incident that occurs.
Configure a Child Incident Filter for a Causal Rule
Note: See Help → Documentation Library → Release Notes, and locate the Support Matrix link for Child
Incident Filter limitations.
The Child Incident Filter tab enables you to create a filter to specify which Child Incidents should be
considered for correlation according to the Causal Rule you are configuring.
For information about each Causal Rules tab:
For information about each Child Incident tab:
Use the Filter Editor Buttons to insert Boolean Operators and to append, insert, and replace expressions in
the Filter String. Use the Drag and Drop feature to make changes to the placement of the expressions in
your Filter String. Click here for more information about using the Filter Editor for Custom Correlations:
l
You can use Custom Incident Attributes, attributes for an incident's Source Node or Source Object, or
both to define how matching incidents should be considered for the Correlation Rule. See Valid
Attributes for more information.
l
When specifying Attribute names and values, NNMi uses the type to determine a match. For example, if
the Attribute type is numeric, NNMi does a numeric comparison. If the Attribute type is textual, NNMi
does a lexographical string comparison. In all cases, when you use the like or not like operator, NNMi
uses a lexographical string comparison. Click here for more information about Attribute types:
n
ifIndex and ifSpeed are numeric Attributes.
n
Any Attribute name that begins wtih "is" (isSnmpInterface, isSnmpNode, isNnmSystemLocal)
represents a Boolean Attribute.
n
All other Attributes are textual.
l
Each set of expressions associated with a Boolean Operator (for example, AND) is treated as if it were
enclosed in parentheses and evaluated together.
l
View the expression displayed under Filter String to see the logic of the expression as it is created.
l
The AND and OR Boolean Operators must contain at least two expressions.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
Page 386 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Filter Editor Buttons and Drag and Drop Feature
Button or
Feature
Description
Append
Appends the current expression (Attribute, Operator,and Value) to the selected
expression already included in the filter string.
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor
location within the Filter String.
Replace
Replaces the selected expression with the expression displayed Left or Right
Expression.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
Delete
Deletes the selected expression.
Note: If the Boolean Operator is selected, the Filter Editor deletes all expressions
associated with the Boolean Operator.
Drag and
Drop
You can drag any of the following items to a new location in the Filter String:
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
n
Click the item you want to move before dragging it to a new location.
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
n
If you are moving the selection down, NNMi places the item below the target
location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an
error message.
To configure a Child Incident Filter for a Causal Rule:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Causal Rules tab.
3. From the Causal Rules table toolbar, do one of the following:
Page 387 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
n
To create a Causal Rule, click the
n
To edit a Causal Rule, click the
to edit, and continue.
n
To delete a Causal Rule, click the
New icon, and continue.
Open icon in the row representing the Causal Rule you want
Delete icon.
4. Create your Causal Rule. (See "Configure a Causal Rule" (on page 382).)
5. Create your Child Incident Configuration . (See "Configure a Child Incident for a Causal Rule" (on
page 384).)
6. Optional. Configure a Child Incident Filter. (See Filter Editor Components).
Filter Editor Components
Component
Description
Attribute
The Attribute on which NNMi searches. See Valid Attributes below for a description
of valid Attributes.
Operator
Use this Operator to establish the relationship between the Attribute and Expression.
See Valid Operators in the table below for the description of each valid Operator.
Expression
Use the Expression to complete the criteria for the Parent Incident configuration. See
Valid Expressions below for a description of the components that you might include
in your Expression.
7. Optional. Configure a Source Object Filter. (See "Configure a Source Object Filter for a Causal Rule"
(on page 393).)
8. Optional. Configure a Source Node Filter. (See "Configure a Source Node Filter for a Causal Rule"
(on page 400).)
9. Click
Save and Close to save your changes and return to the previous form.
Valid Attributes
Attribute
Description
Attribute
The Attribute on which NNMi searches. Valid attributes other than Source Node attributes
depend on the Incident's Source Object. NNMi checks the Source Node as well as the
Source Object for any Capability value.
Note the following when specifying Attributes:
l
Boolean Attributes begin with "is" and must contain the value true or false.
l
Use the following syntax to specify a Custom Incident Attribute (CIA):
valueOfCia(<CIA_Name>)
Note: Check the appropriate Incident form for any valid CIA Names provided by NNMi.
For example: ${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
l
When specifying CIA_Name or CA_Name you can use the asterisk (*) as a wildcard
character to specify one or more characters and a question mark (?) to specify a single
character.
l
If you use attributes that are valid for the Source Node, NNMi uses the Source Node when
comparing values. If you use attributes that are valid for the Source Object, NNMi uses the
Page 388 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Source Object when comparing values. You cannot use attributes that are valid for the
Source Node and Source Object in the same filter.
Possible Source Object choices are as follows:
l
Card [click here for a list of attribute values]
Unique Keys from the Card Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Interface [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for an Interface:
valueOfInterfaceCa(<CA_Name>)
For example: ${child.valueOfInterfaceCA(Role)} =
WAN Connection
Values from the Basics Attributes listed on the Interface Form:
n
hostedOn (Hosted On Node)
Note: You must use the full DNS name for the hostedOn value.
Values from the Interface Form: General Tab:
n
ifName (name configured for the interface)
n
ifAlias (alias configured for the interface)
n
ifDescr (description configured for the interface)
n
ifIndex (index assigned to the interface)
n
ifSpeed (speed configured for the interface)
Note: When entering the value for ifSpeed, use the actual numeric value for the
interface speed. For example, use 10000000 for ifSpeed 10 Mbps.
Addresses from the Interface Form: IP Addresses Tab:
n
ipAddress (IP Address associated with the interface)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <=.
Unique Keys from the Interface Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the parent Node Form:
n
isSnmpInterface (Agent Enabled)
Values from the parent Node Form: General Tab:
n
sysOidInterface (System Object ID)
Values from the Basics Attributes on the associated Device Profile Form:
n
devVendorInterface (Device Vendor)
n
devFamilyInterface (Device Family)
Page 389 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
l
IP Address [click here for a list of attribute values]
Unique Keys from the IP Address Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Node [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for a Node:
valueOfNodeCa(<CA_Name>)
For example: ${valueOfNodeCA(Location)} = USA
Values from the Basics Attributes on the Node Form:
n
hostname (Hostname, case-sensitive)
n
mgmtIPAddress (Management Address)
n
isSnmpNode (Agent Enabled)
n
isNnmSystemLocal (NNMi Management Server)
Values from the Node Form: General Tab:
n
sysName (System Name)
n
sysContact (System Contact)
n
sysLocation (System Location)
n
sysOidNode (System Object ID)
Addresses from the Node Form: IP Addresses Tab:
n
hostedIPAddress (Address)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <= .
Unique Keys from the Node Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the associated Device Profile Form:
n
devVendorNode (Device Vendor)
n
devFamillyNode (Device Family)
Values from the associated entry on the Regional Manager Form: Connection Tab:
n
nnmSystemName (Hostname, case-sensitive)
(NNMi Advanced) If the Global Network Management feature is enabled, this attribute
value identifies a Regional Manager (NNMi management server).
Page 390 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute Description
Valid Operator Values
Operator
Description
=
Finds all values equal to the value specified.
Click here for examples.
Match any incident with a CIA value of 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
Match any incident with the Source Object's Capability equal to
com.hp.nnm.capability.card.fru
$(capability) = com.hp.nnm.capability.card.fru
!=
Finds all values not equal to the value specified.
Click here for an example.
Match any incident with Device Vendor for the interface (Source Object) not equal to Cisco:
${devVendorInterface} != Cisco
<
Finds all values less than the value specified.
Click here for an example.
Match any incident with a CIA value of less than 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} < 5
<=
Finds all values less than or equal to the value specified.
Click here for examples.
Match any incident with a CIA value of less than or equal to 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} <= 5
>
Finds all values greater than the value specified.
Click here for an example.
Match any incident with a CIA value of greater than 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} > 5
>=
Finds all values greater than or equal to the value specified.
Click here for an example.
Match any incident with a Source Object's (interface speed) ifSpeed value of 10Mbps:
${ifSpeed} >= 10000000
is not
null
Finds all non-blank values.
Click here for an example.
Match any incident with a Source Object's (interface name) ifName attribute that contains a
Page 391 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
value:
${ifName} is not null
is null
Finds all blank values.
Click here for an example.
Match any incident with a Source Object's (interface name) ifName attribute that does not
contain a value:
${ifName} is null
like
Finds matches using the syntax defined for Java regular expressions. See the Pattern (Java
Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Object's (interface description) ifDesc attribute that includes
Serial followed by one or more digits:
${ifDesc} like Serial\d+
Match any incident with a Source Object's (interface alias) ifAlias attribute that contains
EtherChannel (for example, PAgPEtherChannel Group 1).
Note: The . (period) indicates any alphanumeric character.
${ifAlias} like .*EtherChannel.*
Match any incident with a CIA attribute value of Chassis Fan Tray followed by a digit and
Object Identifier (OID) of .1.3.6.1.4.1.9.9.13.1.4.1.3
Note: To include literal strings in the value, enclose the string value in \Q<literal_value>\E as
shown in the following example.
${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.3\E)} like Chassis Fan Tray \d
Page 392 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
not like
Finds all matches that do not have the values specified using the syntax defined for Java
regular expressions. See the Pattern (Java Platform SE6) API documentation at :
http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html for more information.
Note: To include literal string values in the Value attribute, enclose the string value in
\Q<literal_value>\E .
The period asterisk (.*) characters mean any number of characters of any type at this
location.
The period (.) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Object's (interface name) ifName value that does not
include rtr:
${ifName} not like .*rtr.*
Valid Expressions
Attribute
Description
Expression
The value or pattern for which you want NNMi to search.
Note the following:
l
The expression can include a valid Attribute.
l
The value or pattern you want to match is case sensitive.
l
When entering the value for ifSpeed, use the actual numeric value for the interface
speed. For example, use 10000000 for ifSpeed 10 Mbps.
Configure a Source Object Filter for a Causal Rule
The Source Filter tab enables you to create a filter to specify which Source Object should be used for the
Parent Incident that is generated for this Causal Rule.
Note: Create only one Source Object Filter for a Causal Rule. If you select Use Child Incident's Source
Object for Parent , NNMi ignores any Source Object Filter you configure.
For information about each Causal Rules tab:
For information about each Child Incident tab:
Use the Filter Editor Buttons to insert Boolean Operators and to append, insert, and replace expressions in
the Filter String. Use the Drag and Drop feature to make changes to the placement of the expressions in
your Filter String. Click here for more information about using the Filter Editor for Custom Correlations:
l
You can use Custom Incident Attributes, attributes for an incident's Source Node or Source Object, or
both to define how matching incidents should be considered for the Correlation Rule. See Valid
Attributes for more information.
l
When specifying Attribute names and values, NNMi uses the type to determine a match. For example, if
the Attribute type is numeric, NNMi does a numeric comparison. If the Attribute type is textual, NNMi
does a lexographical string comparison. In all cases, when you use the like or not like operator, NNMi
uses a lexographical string comparison. Click here for more information about Attribute types:
n
ifIndex and ifSpeed are numeric Attributes.
Page 393 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
n
Any Attribute name that begins wtih "is" (isSnmpInterface, isSnmpNode, isNnmSystemLocal)
represents a Boolean Attribute.
n
All other Attributes are textual.
l
Each set of expressions associated with a Boolean Operator (for example, AND) is treated as if it were
enclosed in parentheses and evaluated together.
l
View the expression displayed under Filter String to see the logic of the expression as it is created.
l
The AND and OR Boolean Operators must contain at least two expressions.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
Filter Editor Buttons and Drag and Drop Feature
Button or
Feature
Description
Append
Appends the current expression (Attribute, Operator,and Value) to the selected
expression already included in the filter string.
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor
location within the Filter String.
Replace
Replaces the selected expression with the expression displayed Left or Right
Expression.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
Delete
Deletes the selected expression.
Note: If the Boolean Operator is selected, the Filter Editor deletes all expressions
associated with the Boolean Operator.
Drag and
Drop
You can drag any of the following items to a new location in the Filter String:
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
n
Click the item you want to move before dragging it to a new location.
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
Page 394 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Button or
Feature
Description
n
If you are moving the selection down, NNMi places the item below the target
location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an
error message.
To configure a Source Object Filter for a Causal Rule:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Causal Rules tab.
3. From the Causal Rules table toolbar, do one of the following:
n
To create a Causal Rule, click the
n
To edit a Causal Rule, click the
to edit, and continue.
n
To delete a Causal Rule, click the
New icon, and continue.
Open icon in the row representing the Causal Rule you want
Delete icon.
4. Create your Causal Rule. (See "Configure a Causal Rule" (on page 382).)
5. Create your Child Incident Configuration . (See "Configure a Child Incident for a Causal Rule" (on
page 384).)
6. Optional. Configure a Child Incident Filter. (See "Configure a Child Incident Filter for a Causal Rule"
(on page 386).)
7. Optional. Configure a Source Object Filter. (See the tables that follow, starting with Filter Editor
Components).
Filter Editor Components
Component
Description
Attribute
The Attribute on which NNMi searches. See Valid Attributes below for a description
of valid Attributes.
Operator
Use this Operator to establish the relationship between the Attribute and Expression.
See Valid Operators in the table below for the description of each valid Operator.
Expression
Use the Expression to complete the criteria for the Parent Incident configuration. See
Valid Expressions below for a description of the components that you might include
in your Expression.
8. Optional. Configure a Source Node Filter. (See "Configure a Source Node Filter for a Causal Rule"
(on page 400).)
9. Click
Save and Close to save your changes and return to the previous form.
Page 395 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Valid Attributes
Attribute
Description
Attribute
The Attribute on which NNMi searches. Valid attributes other than Source Node attributes
depend on the Incident's Source Object. NNMi checks the Source Node as well as the
Source Object for any Capability value.
Note the following when specifying Attributes:
l
Boolean Attributes begin with "is" and must contain the value true or false.
l
Use the following syntax to specify a Custom Incident Attribute (CIA):
valueOfCia(<CIA_Name>)
Note: Check the appropriate Incident form for any valid CIA Names provided by NNMi.
For example: ${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
l
When specifying CIA_Name or CA_Name you can use the asterisk (*) as a wildcard
character to specify one or more characters and a question mark (?) to specify a single
character.
l
If you use attributes that are valid for the Source Node, NNMi uses the Source Node when
comparing values. If you use attributes that are valid for the Source Object, NNMi uses the
Source Object when comparing values. You cannot use attributes that are valid for the
Source Node and Source Object in the same filter.
l
Interface [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for an Interface:
valueOfInterfaceCa(<CA_Name>)
For example: ${child.valueOfInterfaceCA(Role)} =
WAN Connection
Values from the Basics Attributes listed on the Interface Form:
n
hostedOn (Hosted On Node)
Note: You must use the full DNS name for the hostedOn value.
Values from the Interface Form: General Tab:
n
ifName (name configured for the interface)
n
ifAlias (alias configured for the interface)
n
ifDescr (description configured for the interface)
n
ifIndex (index assigned to the interface)
n
ifSpeed (speed configured for the interface)
Note: When entering the value for ifSpeed, use the actual numeric value for the
interface speed. For example, use 10000000 for ifSpeed 10 Mbps.
Addresses from the Interface Form: IP Addresses Tab:
n
ipAddress (IP Address associated with the interface)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <= .
Page 396 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
Unique Keys from the Interface Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the parent Node Form:
n
isSnmpInterface (Agent Enabled)
Values from the parent Node Form: General Tab:
n
sysOidInterface (System Object ID)
Values from the Basics Attributes on the associated Device Profile Form:
l
n
devVendorInterface (Device Vendor)
n
devFamilyInterface (Device Family)
IP Address [click here for a list of attribute values]
Unique Keys from the IP Address Form: Capabilities Tab:
n
l
capability (Unique Key of the Capability)
Node [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for a Node:
valueOfNodeCa(<CA_Name>)
For example: ${valueOfNodeCA(Location)} = USA
Values from the Basics Attributes on the Node Form:
n
hostname (Hostname, case-sensitive)
n
mgmtIPAddress (Management Address)
n
isSnmpNode (Agent Enabled)
n
isNnmSystemLocal (NNMi Management Server)
Values from the Node Form: General Tab:
n
sysName (System Name)
n
sysContact (System Contact)
n
sysLocation (System Location)
n
sysOidNode (System Object ID)
Addresses from the Node Form: IP Addresses Tab:
n
hostedIPAddress (Address)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <= .
Unique Keys from the Node Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the associated Device Profile Form:
Page 397 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
n
devVendorNode (Device Vendor)
n
devFamillyNode (Device Family)
Values from the associated entry on the Regional Manager Form: Connection Tab:
n
nnmSystemName (Hostname, case-sensitive)
(NNMi Advanced) If the Global Network Management feature is enabled, this attribute
value identifies a Regional Manager (NNMi management server).
Page 398 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute Description
Valid Operator Values
Operator
Description
=
Finds all values equal to the value specified.
Click here for examples.
Match any incident with a CIA value of 5 and Object Identifier (OID) of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
!=
Finds all values not equal to the value specified.
Click here for an example.
Match any incident with a Source Object value of Interface with Device Vendor value not
equal to Cisco:
${devVendorInterface} != Cisco
<
Finds all values less than the value specified.
Click here for an example.
Match any incident with a CIA value less than 5 and Object Identifier (OID) value of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} < 5
<=
Finds all values less than or equal to the value specified.
Click here for examples.
Match any incident with a CIA attribute value less than or equal to 5 and Object Identifier
(OID) value of .1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} <= 5
>
Finds all values greater than the value specified.
Click here for an example.
Match any incident with a CIA value greater than 5 and Object Identifier (OID) attribute value
of .1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} > 5
>=
Finds all values greater than or equal to the value specified.
Click here for an example.
Match any incident with a Source Object attribute value of Interface that has an (interface
speed) ifSpeed of 10Mbps:
${ifSpeed} >= 10000000
is not
null
Finds all non-blank values.
Click here for an example.
Match any incident with a Source Object attribute value of Interface that has an (interface
name) ifName value:
${ifName} is not null
Page 399 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
is null
Finds all blank values.
Click here for an example.
Match any incident with a Source Object attribute value of Interface that does not have an
(interface name) ifName value:
${ifName} is null
like
Finds matches using wildcard characters and the question mark.
The asterisk (*) character means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Object attribute value of Interface with a (description) ifDesc
that begins with Serial followed by any number of characters:
${ifDesc} like Serial*
Match any incident with a Source Object attribute value of Interface with an (interface alias)
ifAlias value that begins with EtherChannel (for example, EtherChannel Group 1).
${ifAlias} like EtherChannel*
not like
Finds all matches that do not have the values specified.
The asterisk (*) characters means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Click here for an example.
Match any with a Source Object attribute value of Interface with an (interface name) ifName
value that does not begin with rtr*:
${ifName} not like rtr*
Valid Expressions
Attribute
Description
Expression
The value or pattern for which you want NNMi to search.
Note the following:
l
The expression can include a valid Attribute.
l
The value or pattern you want to match is case sensitive.
l
When entering the value for ifSpeed, use the actual numeric value for the interface
speed. For example, use 10000000 for ifSpeed 10 Mbps.
Configure a Source Node Filter for a Causal Rule
The Source Node Filter tab enables you to create a filter to specify which Source Node should be used for
the Parent Incident that is generated for this Causal Rule.
Page 400 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Note: Create only one Source Node Filter for a Causal Rule. If you select Use Child Incident's Source
Node for Parent , NNMi ignores any Source Node Filter you configure.
For information about each Causal Rules tab:
For information about each Child Incident tab:
Use the Filter Editor Buttons to insert Boolean Operators and to append, insert, and replace expressions in
the Filter String. Use the Drag and Drop feature to make changes to the placement of the expressions in
your Filter String. Click here for more information about using the Filter Editor:
l
You can use Custom Incident Attributes, attributes for an incident's Source Node, or both to define how
matching incidents should be considered for the Causal Rule. See Valid Attributes for more
information.
l
When specifying Attribute names and values, NNMi uses the type to determine a match. For example, if
the Attribute type is Integer, NNMi does a numeric comparison. If the Attribute type is textual, NNMi
does a lexographical string comparison. In all cases, when you use the like or not like operator, NNMi
uses a lexographical string comparison.
l
Each set of expressions associated with a Boolean Operator is treated as if it were enclosed in
parentheses and evaluated together.
l
View the expression displayed under Filter String to see the logic of the expression as it is created.
l
The AND and OR Boolean Operators must contain at least two expressions.
l
The placement of your cursor and the subsequent text that is selected is important when performing
operations using the Additional Filters Editor. For example, you append to or replace, the expression
that is selected.
l
The placement of your cursor and the subsequent text that is selected is especially important when
adding your Boolean operators. See "Add Boolean Operators in the Additional Filters Editor" (on page
191) for more information.
Filter Editor Buttons and Drag and Drop Feature
Button or
Feature
Description
Append
Appends the current expression (Attribute, Operator,and Value) to the selected
expression already included in the filter string.
Insert
Inserts the current expression (Attribute, Operator,and Value) in front of the cursor
location within the Filter String.
Replace
Replaces the selected expression with the expression displayed Left or Right
Expression.
AND
Inserts the AND Boolean Operator in the selected cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
OR
Inserts the OR Boolean Operator in the current cursor location.
Note: View the expression displayed under Filter String to see the logic of the
expression as it is created.
Delete
Page 401 of 1087
Deletes the selected expression.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Button or
Feature
Description
Note: If the Boolean Operator is selected, the Filter Editor deletes all expressions
associated with the Boolean Operator.
Drag and
Drop
You can drag any of the following items to a new location in the Filter String:
n
Filter Editor Options: AND, OR, NOT, EXISTS, NOT EXISTS
n
Filter Expression (Attribute, Operator and Value)
When moving items in the Filter String, note the following:
n
Click the item you want to move before dragging it to a new location.
n
As you drag a selected item, an underline indicates the target location.
n
If you are moving the selection up, NNMi places the item above the target location.
n
If you are moving the selection down, NNMi places the item below the target
location.
n
If you attempt to move the selection to an invalid target location, NNMi displays an
error message.
To configure a Source Node Filter for a Causal Rule:
1. Navigate to the Custom Correlation Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Causal Rules tab.
3. From the Causal Rules table toolbar, do one of the following:
n
To create a Causal Rule, click the
n
To edit a Causal Rule, click the
to edit, and continue.
n
To delete a Causal Rule, click the
New icon, and continue.
Open icon in the row representing the Causal Rule you want
Delete icon.
4. Create your Causal Rule. (See "Configure a Causal Rule" (on page 382).)
5. Create your Child Incident Configuration . (See "Configure a Child Incident for a Causal Rule" (on
page 384).)
6. Optional. Configure a Child Incident Filter. (See "Configure a Child Incident Filter for a Causal Rule"
(on page 386).)
7. Optional. Configure a Source Object Filter. (See "Configure a Source Object Filter for a Causal Rule"
(on page 393).)
8. Optional. Configure a Source Node Filter. (See the tables that follow, starting with Filter Editor
Page 402 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Components.)
Filter Editor Components
Component
Description
Attribute
The Attribute on which NNMi searches. See Valid Attributes below for a description
of valid Attributes.
Operator
Use this Operator to establish the relationship between the Attribute and Expression.
See Valid Operators in the table below for the description of each valid Operator.
Expression
Use the Expression to complete the criteria for the Parent Incident configuration. See
Valid Expressions below for a description of the components that you might include
in your Expression.
9. Click
Save and Close to save your changes and return to the previous form.
Valid Attributes
Attribute
Description
Attribute
The Attribute on which NNMi searches.
Note the following when specifying Attributes:
l
Boolean Attributes begin with "is" and must contain the value true or false.
l
Use the following syntax to specify a Custom Incident Attribute (CIA):
valueOfCia(<CIA_Name>)
Note: Check the appropriate Incident form for any valid CIA Names provided by NNMi.
For example: ${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
l
When specifying CIA_Name or CA_Name you can use the asterisk (*) as a wildcard
character to specify one or more characters and a question mark (?) to specify a single
character.
l
Node [click here for a list of attribute values]
Use the following syntax to specify a Custom Attribute (CA) for a Node:
valueOfNodeCa(<CA_Name>)
For example: ${valueOfNodeCA(Location)} = USA
Values from the Basics Attributes on the Node Form:
n
hostname (Hostname, case-sensitive)
n
mgmtIPAddress (Management Address)
n
isSnmpNode (Agent Enabled)
n
isNnmSystemLocal (NNMi Management Server)
Values from the Node Form: General Tab:
n
sysName (System Name)
n
sysContact (System Contact)
Page 403 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute
Description
n
sysLocation (System Location)
n
sysOidNode (System Object ID)
Addresses from the Node Form: IP Addresses Tab:
n
hostedIPAddress (Address)
Because NNMi uses a lexicographical compare when evaluating IP addresses, it is
recommended that you use the like and not like operators to specify IP address
ranges rather than using the following operators: >, >=, <, or <=.
Unique Keys from the Node Form: Capabilities Tab:
n
capability (Unique Key of the Capability)
Values from the Basics Attributes on the associated Device Profile Form:
n
devVendorNode (Device Vendor)
n
devFamillyNode (Device Family)
Values from the associated entry on the Regional Manager Form: Connection Tab:
n
nnmSystemName (Hostname, case-sensitive)
(NNMi Advanced) If the Global Network Management feature is enabled, this attribute
value identifies a Regional Manager (NNMi management server).
Page 404 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Attribute Description
Valid Operator Values
Operator
Description
=
Finds all values equal to the value specified.
Click here for examples.
Match any incident with a CIA value of 5 and Object Identifier (OID) value of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} = 5
!=
Finds all values not equal to the value specified.
Click here for an example.
Match any incident with a Source Node value that has a Device Vendor value not equal to
Cisco:
${devVendorNode} != Cisco
<
Finds all values less than the value specified.
Click here for an example.
Match any incident with a CIA value less than 5 and Object Identifier (OID) value of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia(\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} < 5
<=
Finds all values less than or equal to the value specified.
Click here for examples.
Match any incident with a CIA value less than or equal to 5 and Object Identifier (OID) value
of .1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} <= 5
>
Finds all values greater than the value specified.
Click here for an example.
Match any incident with a CIA value greater than 5 and Object Identifier (OID) value of
.1.3.6.1.4.1.9.9.106.2.0.1:
${valueOfCia (\Q.1.3.6.1.4.1.9.9.106.2.0.1\E)} > 5
>=
Finds all values greater than or equal to the value specified.
is not
null
Finds all non-blank values.
Click here for an example.
Match any incident with a Source Node that has a (system contact name) sysContact value:
${sysContact} is not null
is null
Finds all blank values.
Click here for an example.
Match any incident with a Source Node that does not have a (system contact name)
sysContact value:
Page 405 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Operator
Description
${sysContact} is null
like
Finds matches using wildcard characters and the question mark.
The asterisk (*) character means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Node that has a (system location) sysLocation value that
begins with Bldg5:
${syslocation} like Bldg5*
not like
Finds all matches that do not have the values specified.
The asterisk (*) characters means any number of characters of any type at this location.
The question mark (?) character means any single character of any type at this location.
Click here for an example.
Match any incident with a Source Node that has a (system location) sysLocation value that
does not begin with Bldg5:
${sysLocation} not like Bldg5*
Valid Expressions
Attribute
Description
Expression
The value or pattern for which you want NNMi to search.
Note the following:
l
The expression can include a valid Attribute.
l
The value or pattern you want to match is case sensitive.
Causal Rule Example
Tip: Use these steps as a guideline for creating your own Causal Rules.
This example creates a Causal Rule that generates a new CardHealthProblem Parent Incident. It uses the
traps described in the following table to determine the following:
• Whether there is a temperature problem or diagnostic failure for a Field Replaceable Unit (FRU) Card
module
• Whether the source of the problem is a fan, a power supply, or both.
Trap Descriptions
Trap
Description
FruModuleStatusChange
Indicates a temperature problem (14) or diagnostic failure (11)
for the Field Replaceable Unit (FRU) card module
CiscoEnvMonFanNotification
Indicates the problem is related to a fan. The example Causal
Rule uses this trap to obtain the name of the fan.
Page 406 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Trap
Description
CiscoEnvMonSuppStatusChangeNotif Indicates the problem is related to the Power Supply.
Using the Causal Rule described in this example, NNMi generates a new CardHealthProblem Parent
Incident when NNMi determines the following:
l
The Source Object for the Child Incident is a Field Replaceable Unit (FRU) card.
Note: NNMi checks for the com.hp.nnm.capability.card.fru capability to determine whether the Source
Object is an FRU card.
l
The FruModuleStatusChange trap returns a value of either 14 (temperature problem) or 11 (diagnostic
failure).
To configure the CardHealth Causal Rule Basics information:
1. Navigate to the Causal Rule form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Custom Correlation Configuration.
2. Navigate to the Causal Rules tab.
3. From the Causal Rules table toolbar, click the
New icon.
4. In the Name attribute, enter a unique name that will help you to identify the Causal Rule. In this
example, the Causal Rule Name is Card Health.
5. In the Author attribute, either enter a name that identifies the person who is creating the Causal Rule
or keep the default value Customer.
6. Make sure Enabled
is checked to indicate the NNMi Causal Engine should use this Causal Rule
when evaluating incidents.
7. To create a new Incident Configuration for the Parent Incident, in the Parent Incident Lookup Field,
select
New.
8. In the Management Event Configuration form, enter the Basics information as follows:
a. In the Name attribute, enter CardHealthProblem for the Name value.
b. Make sure Enabled
is checked to indicate the NNMi Causal Engine should use this
Causal Rule when evaluating incidents.
c. In the Categories Lookup Field, select
Categories.
d. In the Family Lookup Field, select
Families.
e. In the Severity Lookup Field, select
Severities.
Quick Find and select Fault from the list of incident
Quick Find and then Card from the list of incident
Quick Find and then Critical from the list of incident
f. In the Message Format attribute, enter the following: Card
$.1.3.6.1.2.1.47.1.1.1.1.7.5000 with $.1.3.6.1.4.1.9.9.13.1.4.1.2 and
Power Supply not functioning
Page 407 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
NNMi displays the name of the Card using the Object Identifier (OID) value of
$.1.3.6.1.2.1.47.1.1.1.1.7.5000. NNMi displays the name of the Fan using the OID value of
$.1.3.6.1.4.1.9.9.13.1.4.1.2.
g. Click Save and Close to save your changes and return to the Causal Rule form.
9. In the Correlation Nature select Root Cause from the drop-down list.
10. In Common Child Incident Attribute, enter ${hostname}.
11. In the Correlation Window Duration attribute, keep the default value of 5 minutes.
12. Use the Description attribute to provide additional information that you would like to store about the
current incident configuration. This description applies only to the configuration entry.
To configure the first Child Incident (CiscoModuleStatusChange):
1. In the Causal Rule form, navigate to the Child Incidents tab.
2. Click the
New icon to configure the first Child Incident.
3. In the Name attribute of the Child Incident Configuration form, enter FRU Card.
4. In the Child Incident Lookup Field, select
the list of incident configurations.
Quick Find and then CiscoModuleStatusChange from
5. To forward the Card name to the new Parent Incident, in Forward Child Custom Incident Attributes,
enter .1.3.6.1.2.1.47.1.1.1.1.7.5000.
6. Check to enable Use Child Incident's Source Object for Parent
7. Check to enable Use Child Incident's Source Node for Parent
.
.
To configure the first Child Incident Filter:
1. In the Child Incident Configuration form, navigate to the Child Incident Filter tab.
Next, create the following filter: (capability = com.hp.nnm.capability.card.fru AND
${valueOfCia(\Q.1.3.6.1.4.1.9.9.117.1.2.1.1.2.5000\E)} = 11) OR
${valueOfCia(\Q.1.3.6.1.4.1.9.9.117.1.2.1.1.2.5000\E)} = 14)
2. In the Attribute field, enter capability.
3. In the Operator field, select = from the drop-down menu.
4. In the Expression field, enter com.hp.nnm.capability.card.fru.
5. Click Append.
6. Select Insert from the drop-down menu.
7. Click AND.
8. Click to highlight AND in the Child Incident Filter Expression.
9. Select Append from the drop-down menu.
10. Click OR.
11. Click to highlight OR in the Child Incident Filter Expression.
12. In the Attribute field, enter ${valueOfCia(\Q.1.3.6.1.4.1.9.9.117.1.2.1.1.2.5000\E)}.
13. In the Operator field, select = from the drop-down menu.
14. In the Expression field, enter 11.
Page 408 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
15. Click Append.
16. In the Attribute field, enter ${valueOfCia(\Q.1.3.6.1.4.1.9.9.117.1.2.1.1.2.5000\E)}.
17. In the Operator field, select = from the drop-down menu.
18. In the Expression field, enter 14.
19. Click to highlight OR in the Child Incident Filter Expression.
20. Click Append.
21. Click Save and Close to return to the Causal Rule form.
To configure the second Child Incident (CiscoEnvMonFanNotification):
1. In the Causal Rule form, navigate to the Child Incidents tab.
2. Click the
New icon to configure the second Child Incident.
3. In the Name attribute of the Child Incident Configuration form, enter Chassis Fan.
4. In the Child Incident Lookup Field, select
from the list of incident configurations.
Quick Find and then CiscoEnvMonFanNotification
5. To forward the Fan name to the new Parent Incident, in Forward Child Custom Incident Attributes,
enter .1.3.6.1.2.1.47.1.1.1.1.7.5000.
To configure the second Child Incident Filter:
1. In the Child Incident Configuration form, navigate to the Child Incident Filter tab.
Next, create the following filter: (${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.2\E)} =
Chassis Fan Tray 1 AND ${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.3\E)} = 3)
2. In the Attribute field, enter ${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.2\E)}.
3. In the Operator field, select = from the drop-down menu.
4. In the Expression field, enter Chassis Fan Tray 1.
5. Click Append.
6. Select Insert from the drop-down menu.
7. Click AND.
8. In the Attribute field, enter ${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.3\E)}.
9. In the Operator field, select = from the drop-down menu.
10. In the Expression field, enter 3.
11. Click Append.
12. Click Save and Close to return to the Causal Rule form.
To configure the third Child Incident (CiscoEnvMonSuppStatusChangeNotif):
1. In the Causal Rule form, navigate to the Child Incidents tab.
2. Click the
New icon to configure the third Child Incident.
3. In the Name attribute of the Child Incident Configuration form, enter Chassis Power.
4. In the Child Incident Lookup Field, select
Page 409 of 1087
Quick Find and then
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
CiscoEnvMonSuppStatusChangeNotif from the list of incident configurations.
5. To forward the Fan name to the new Parent Incident, in Forward Child Custom Incident Attributes,
enter ${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.2\E)}.
To configure the third Child Incident Filter:
1. In the Child Incident Configuration form, navigate to the Child Incident Filter tab.
Next, create the following filter: (${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.3\E} = 3}
AND ${valueOfCia(\Q.1.3.6.1.4.1.9.9.117.1.2.1.1.2.5000\E} = Power Supply 1,
WS-CAC-1300W)
2. In the Attribute field, enter ${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.3\E)}.
3. In the Operator field, select = from the drop-down menu.
4. In the Expression field, enter 3.
5. Click Append.
6. Select Insert from the drop-down menu.
7. Click AND.
8. In the Attribute field, enter ${valueOfCia(\Q.1.3.6.1.4.1.9.9.13.1.4.1.2\E)}.
9. In the Operator field, select = from the drop-down menu.
10. In the Expression field, enter Power Supply 1, WS-CAC-1300W.
11. Click Append.
12. Click Save and Close to save your changes and return to the Causal Rule form.
13. Click Save and Close to save your changes and return to the Custom Correlation Configuration
form.
14. Click Save and Close to save the Custom Correlation Configuration.
See "Correlation Rule Example" (on page 379) for an example of creating a Correlation Rule.
Configure an Action for an Incident
You can configure actions to automatically run at any point in the incident lifecycle. For example, you might
want to configure an action to occur when an incident of the type you are configuring is generated
(Registered). When an incident is generated, you might want to automatically open a trouble ticket or send
email or page your network operator. After the incident is Closed, you might want to automatically close
the trouble ticket.
Note: Your actions will not be executed until you enable the Actions configuration by either clicking
Enable
on the Actions tab or using the Actions → Enable Configuration option.
You can provide the required information within the following contexts:
"Configure Actions for an SNMP Trap Incident" (on page 567)
"Configure Actions for a Remote NNM 6.x/7.x Event Incident" (on page 712)
"Configure Actions for a Management Event Incident" (on page 846)
Page 410 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Lifecycle Transition Action Form
Use this form to enter the command you want to run when an incident of the type you are configuring is at a
particular Lifecycle State. For example, when an incident is generated (Registered), you might want to
automatically open a trouble ticket or email or page your network operator.
You can provide the required information within the following contexts:
"Lifecycle Transition Action Form (SNMP Trap Incidents)" (on page 568)
"Lifecycle Transition Action Form (Remote NNM 6.x/7.x Events)" (on page 713)
"Lifecycle Transition Action Form (Management Events)" (on page 847)
Valid Parameters for Configuring Incident Actions (Management Events)
When configuring incident actions, you may want to use incident information as part of the action. NNMi
provides the following parameter values. Use these parameters as variables in your Jython or executable
files.
Tip: See the Using the Incident Form for more information about the parameter values.
Note: NNMi stores varbind values as custom incident attributes (CIAs).
See "Lifecycle Transition Action Form" (on page 411) for more information about configuring incident
actions.
Valid Parameters Visible From an Incident's Form
Parameter Value
Description
$category, $cat
Value of the Category attribute in the Incident form.
$count, $cnt
Value representing the number of Custom Incident Attributes that appear in
the Incident form.
$family, $fam
Value from the Family attribute in the Incident form.
$firstOccurrenceTime,
$fot
Value from the First Occurrence Time attribute in the incident form.
$lastOccurrenceTime,
$lot
Value from the Last Occurrence Time attribute in the incident form.
$lifecycleState, $lcs
Value from the Lifecycle State attribute in the Incident form.
$name
Value of the Name attribute from the incident configuration.
$nature, $nat
Value from the Nature attribute in the Incident form.
$origin, $ori
Value from the Origin attribute in the Incident form.
$originOccurrenceTime,
$oot
Value from the Origin Occurrence Time attribute in the incident form.
$priority, $pri
Value from the Priority attribute in the Incident form.
$severity, $sev
Value of the Severity attribute of the Incident form.
Page 411 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Valid Parameters Visible from a Node Form
Parameter Value
Description
$managementAddress, $mga
Value from the Management Address attribute of the
incident's source Node's form or SNMP Agent form.
$otherSideOfConnectionManagementAddress, If the incident's Source Node is part of a Layer 2
$oma
connection, this attribute is the value of the Management
Address of a node on the other side of the Layer 2
connection.
$sourceNodeLongName, $sln
The fully-qualified DNS name as displayed in the
Hostname attribute of the incident's source Node's form.
$sourceNodeName, $snn
Value from the Name attribute of the incident's source
Node's form.
$sysContact, $sct
Value from the System Contact attribute of the incident's
source Node form: General tab.
$sysLocation, $slc
Value from the System Location attribute of the
incident's source Node form: General tab.
Valid Parameters Visible from an Interface Form
Parameter Value
Description
$ifAlias, $ifa
Value from the IfAlias attribute for the interface that is the incident's source object.
$ifConfigDupSetting, Configured Duplex Setting on the port associated with the interface that is the
$icd
incident's source object.
$ifDesc, $idc
Value from the ifDesc attribute for the interface that is the incident's source object.
$ifIndex, $idx
Value from the ifIndex attribute for the interface that is the incident's source object.
$ifIpAddr, $iia
IP Address values associated with the interface that is the incident's source
object. If multiple IPaddresses are associated with the interface, this parameter
returns a comma-separated list.
$ifName, $ifn
Value from the ifName attribute for the interface that is the incident's source
object.
$ifPhysAddr, $ipa
Value from the Physical Address attribute for the interface that is the incident's
source object.
$ifSpeed, $isp
Value from the ifSpeed attribute for the interface that is the incident's souce
object.
$ifType, $itp
Value from the ifType attribute for the interface that is the incident's souce object.
Valid Parameters Visible from a Layer 2 Connection Form
Parameter Value
Description
$otherSideOfConnectionConfigDupSetting, If the incident's source Node is part of a Layer 2 connection,
$ocd
Page 412 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Parameter Value
Description
this parameter contains the Configured Duplex Setting on
the port associated with the interface on the other side of
the connection.
$otherSideOfConnectionIfAlias, $oia
If the incident's Source Node is part of a Layer 2 connection,
this parameter is the value of the ifAlias of one of the
interfaces on the other side of the Layer 2 connection.
$otherSideOfConnectionIfDesc, $odc
If the incident's Source Node is part of a Layer 2 connection,
this parameter contains the ifDescr attribute value for the
interface on the other side of the Layer 2 connection.
$otherSideOfConnectionIfIndex, $odx
If the incident's Source Node is part of a Layer 2 connection,
this parameter contains the ifIndex attribute value for the
interface on the other side of the connection.
$otherSideOfConnectionIfName, $ofn
If the incident's Source Node is part of a Layer 2 connection,
this parameter contains the ifName attribute value for the
interface on the other side of the connection.
Valid Parameters Visible from a VLAN Form
Parameter
Value
$impVlanIds, $ivi
Description
Value from the VLAN Id attribute associated with the interface that is the incident's
source object. To access this information from an interface form, navigate to the
VLAN Port tab and open the form for the VLAN of interest. If the interface is part of
more than one VLAN, this parameter returns a comma-separated list.
$impVlanNames, Value from the VLAN Name attribute associated with the interface that is the
$ivn
incident's source object. To access this information from an interface form, navigate
to the VLAN Ports tab of the Interface form. If the interface is part of more than one
VLAN, this parameter returns a comma-separated list.
Valid Parameters Not Visible From a Form
Parameter Value
Description
$id
Unique Object Identifier attribute value for the incident (unique across the
entire NNMi Database).
$firstOccurrenceTimeMS,
$fms
Value from the First Occurrence Time attribute in the incident form,
converted to millseconds (measured since January 1, 1970, 00:00:00 GMT
- Greenwich Mean Time).
$lastOccurrenceTimeMS,
$lms
Value from the Last Occurrence Time attribute in the incident form,
converted to millseconds (measured since January 1, 1970, 00:00:00 GMT
- Greenwich Mean Time).
$oid
Value of the unique object identifier (oid) for the incident configuration that
originated from either an SNMP trap, Management Event, or Remote NNM
6.x or 7.x event.
Page 413 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Parameter Value
Description
$otherSideOfConnection,
$osc
If the incident's Source Node is part of a Layer 2 connection, this attribute is
the following combination of values for the node and one of its interfaces
on the other side of the Layer 2 connection:
The fully-qualified DNS name of the node appended with the interface
Name in the following format: <fully-qualified DNS name>[interface_name]
$originOccurrenceTimeMS, Value from the Origin Occurrence Time attribute in the incident form,
$oms
converted to millseconds (measured since January 1, 1970, 00:00:00 GMT
- Greenwich Mean Time).
$sourceNodeUuid, $snu
Universally Unique Object Identifier attribute value of the source node
object for the incident (unique across all databases). This identifier
distinguishes the source node object instance from all other node objects.
$sourceObjectClass, $soc
Value of the object class for the object you want to include. Use this
parameter when you need to request more details of a class of objects
through a web service. Examples of object classes include:
com.hp.ov.nms.model.core.Interface and
com.hp.ov.nms.model.snmp.SnmpAgent.
$sourceObjectName, $son
Value from the Name attribute of the source object. For example, an
interface object is named according to the MIB ifName. Each ifName varies
according to the vendor's conventions. Using the name 4/1 as an
example, 4 represents the board number and 1 represents the port
number.
$sourceObjectUuid, $sou
Universally Unique Object Identifier attribute value of the source object for
the incident (unique across all databases). This identifier distinguishes the
source object instance from all other similar object instances..
$uuid
Universally Unique Object Identifier attribute value of the incident (unique
across all databases). This identifier distinguishes the incident object
instance from all other incident objects.
Valid Parameters Established in Custom Incident Attributes
Parameter
Value
$<position_
number>
Description
Value of the custom incident attribute (CIA) position number for any CIA that originated
from a varbind or was added by NNMi. For example, to indicate you want to use the
varbind in position 1, enter: $1
NNMi stores varbind values as Custom Incident Attributes. If you know the varbind position
number, use this parameter.
$<CIA_
name>
Value of the name that is used for the custom incident attribute. For example,
$mycompany.mycia. NNMi provides CIA values for configuring Management Events. See
Custom Incident Attributes Provided by NNMi for more information about custom incident
attributes.
$<CIA_
oid>
Value of the object identifier for any custom incident attribute that originated as a varbind.
For example, $.1.3.6.1.6.3.1.1.5.1. Use this parameter when you are not certain of
a custom incident attribute (varbind) position number.
Page 414 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Parameter
Value
$*
Description
Used to indicate you want all of the custom incident attribute values originating as
varbinds, to be passed to the action configuration. Each varbind is returned in the following
format: $<CIA_name>:<CIA_value> in which the custom incident attribute name appears
followed by the custom incident attribute value.
The function described in the following table replaces the specified numeric value with the associated text
value stored in the CIA.
Note: The associated MIB must have been loaded using the nnmloadmib.ovpl command.
Functions to Generate Values Within Incident Messages
Function
Description
$text($<position_
number>)
The <position_number> argument specifies the numeric value of the custom incident
attribute (CIA) position number for any CIA that originated from a varbind or was
added by NNMi. For example, to indicate you want to use the varbind in position 1,
enter: $1.
After the function runs, NNMi replaces the numeric value with the text value stored in
the CIA.
Note: If a text value is not available, NNMi returns the numeric value.
$text($<CIA_
oid>)
The <CIA_oid> argument specifies the object identifier for any custom incident
attribute that originated as a varbind. For example, $.1.3.6.1.6.3.1.1.5.1. Use
this argument to the $text function when you are not certain of a custom incident
attribute (varbind) position number.
After the function runs, NNMi replaces the numeric value with the text value stored in
the CIA.
Note: If a text value is not available, NNMi returns the numeric value.
Handling Special Characters in Action Arguments
In some cases, NNMi requires or inserts double quotes or escape characters in arguments that are passed
to the Jython file, executable, or shell script using the Command attribute.
Note: Shell commands are not allowed in the Command attribute. If you need to use shell commands,
place them in a shell script file and reference that file from the Command attribute.
The following table describes how to handle special characters included as arguments to your Jython files,
executables, or shell scripts.
Handling Special Characters in Arguments
Circumstance
Result
If the following special
characters are requested as a
single argument to a Jython,
executable, shell script, or shell
command:
The argument (containing the special character) must be wrapped in
double quotes. For example, "Hello;World".
, ; & > < (space) | =
Page 415 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Circumstance
Result
Request all available CIA
name/value pairs for a
particular incident
The $* argument returns a parsed string. For this example, the
available CIA name/value pairs are:
l
$1 = 123
l
$com.mycompany.mycia = 012345
l
$.1.3.6.1.2.1.2.2.1.1 = 1007
$*
Example Command
echoScript.bat $*
NNMi returns the following string in response to the command:
l
Windows:
"1: 123, com.mycompany.mycia:012345,
.1.3.6.1.2.1.2.2.1.1:1007"
l
UNIX:
1: 123, com.mycompany.mycia:012345,
.1.3.6.1.2.1.2.2.1.1:1007
Request specific CIA values as
an argument to an action
command
To request specific CIA values, use the $ followed by the CIA name
$<CIA name, position, or OID>
echoScript.bat $1 $com.mycompany.mycia
$.1.3.6.1.2.1.2.2.1.1
Example Command
For this example, the CIA name/value pairs are:
l
$1 = 123
l
$com.mycompany.mycia = 012345
l
$.1.3.6.1.2.1.2.2.1.1 = 1007
NNMi returns the following string in response to the command:
l
l
Windows:
123 012345
1007
UNIX:
123 012345
1007
Page 416 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Circumstance
Result
If an invalid CIA name, position,
or OID is requested as an
argument to an action
command
If the trap or event does not contain one or more of the requested
CIAs, NNMi passes error messages as arguments.
UNIX:
Invalid or unknown cia position 1
Invalid or unknown cia com.mycompany.mycia
Invalid or unknown cia .1.3.6.1.2.1.2.2.1.1
Windows: NNMi encloses each CIA value in double quotes.
Invalid or unknown cia "position 1"
Invalid or unknown cia "com.mycompany.mycia"
Invalid or unknown cia ".1.3.6.1.2.1.2.2.1.1"
Use $* in your incident action
scripts
UNIX:
It is recommended that you do not use $* (shell variable substitution)
in your incident action scripts. If you do use $* within the shell script,
specifying $* expands into the arguments and are rescanned. This
means that blanks in arguments will result in multiple arguments.
If you want to use shell variable substitution, use the "$@" instead so
that blanks in arguments are ignored.
Use arguments to Jython
methods
Enclose any argument that is not preceded with a "$" (dollar sign) in
double quotes. For example, jythonMethod($Severity, "Hello; World").
Configure Diagnostics for an Incident (NNM iSPI NET)
HP Network Node Manager iSPI Network Engineering Toolset Software provides a set of Diagnostics
(Flow Definitions) that can be run on the Source Node each time an incident reaches a specified Lifecycle
State (for example, as soon as an incident becomes Registered).
These Diagnostics are sets of automated commands specific to one or more device types, including Cisco
routers and switches, Cisco switch/routers, and Nortel switches.
See "Configure Device Profiles" (on page 134) for more information about device types . See "Diagnostics
(Flows) Provided by NNM iSPI NET" (on page 418) for more information about the Diagnostics provided
by NNMi.
Configuring NNMi to automatically gather diagnostic information about the Source Node whenever a
specified incident reaches a selected Lifecycle State is a two-step process:
1. Specify the Node Group providing the required information within one of the following contexts:
n
"Configure Node Settings for an SNMP Trap Incident" (on page 485)
n
"Configure Node Settings for a Remote NNM 6.x/7.x Event Incident" (on page 630)
n
"Configure Node Settings for a Management Event Incident" (on page 774)
2. Specify the Diagnostics (Flow Definitions) providing the required information within one of the
following contexts:
Page 417 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
n
"Configure Diagnostics Selections for a Node Group (SNMP Trap Incident) (NNM iSPI NET)" (on
page 522)
n
"Configure Diagnostics Selections for a Node Group (Remote NNM 6.x/7.x Events)" (on page
669)
n
"Configure Diagnostics Selections for a Node Group (Management Events)" (on page 809)
Diagnostic Selections Form (NNM iSPI NET)
With HP Network Node Manager iSPI Network Engineering Toolset Software, the Diagnostic Selections
form enables you to configure NNMi to automatically gather diagnostic information for the Incident you are
configuring. When using this form, you specify the diagnostics you want to run on each applicable node in
the specified Node Group.
You can provide the required information within the following contexts:
"Configure Diagnostics Selections for a Node Group (SNMP Trap Incident) (NNM iSPI NET)" (on page
522)
"Configure Diagnostics Selections for a Node Group (Remote NNM 6.x/7.x Events)" (on page 669)
"Configure Diagnostics Selections for a Node Group (Management Events)" (on page 809)
Diagnostics (Flows) Provided by NNM iSPI NET
The HP Network Node Manager iSPI Network Engineering Toolset Software Diagnostics (Flows) are sets
of automated commands specific to one or more device types. You can associate these Diagnostics with
specific incident configurations. After you associate a Diagnostic with an incident configuration and specify
the Lifecycle State for which the Diagnostic should run, the Diagnostic automatically runs on the Source
Node for the incident whenever the specified Lifecycle State is reached. See "Configure Diagnostics for an
Incident (NNM iSPI NET)" (on page 417) for more information.
NNMi also associates these Diagnostics with each node to which the Diagnostics apply. To view the
Diagnostics invoked for each node, open the Node form for any node of interest. See Node Form:
Diagnostics Tab for more information.
NNMi provides Diagnostics (Flows) for the following device types:
l
Cisco router
l
Cisco switch
l
Cisco switch/router (see Cisco router and Cisco switch)
l
Nortel switch
Cisco Router Diagnostics (Flow Definitions) Provided by NNMi
Name
Description
Cisco
Router
Baseline
Information
Uses a series of show commands to determine the current configuration of a Cisco router. It
first displays the router's and NNMi management server's current times. Next, it invokes a
series of commands on the router and formats these results on the summary page. Click
here for a list of the commands included in this Diagnostic.
show version
show protocol
Page 418 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
show interface summary
show ip route
show ip protocol
show ip traffic
show vlans
show cdp
show cdp entry
show cdp neighbors
show log
show stacks
Cisco
Show IP
Route
Obtains routing information using the show ip route command.
Cisco
Route To
Node
Diagnostic
Note: This Diagnostic Flow is not associated with an NNMi incident or node object and can
only be run from Operations Orchestration Central's Flow Library. Before the
Diagnostic runs, you are prompted for access information for the source router and
target device node.
Determines failures of either ping or traceroute to a target node. Uses the router to perform
a ping and a traceroute to a target node.
Click here for a list of commands included in this Diagnostic
ping target
traceroute target
Cisco
Interface
Diagnostic
Performs a number of diagnostic checks on a specified interface on the Cisco router.
Diagnostics performed include whether the link is Down while the interface is Up. The
following error counts are checked:
l
Input errors
l
CRC errors
l
Frame errors
l
Overrun errors
l
Ignored errors
Cisco Switch Diagnostics (Flow Definitions) Provided by NNMi
Name
Description
Cisco
Switch
Baseline
Information
Uses a series of show commands to determine the current configuration of a Cisco switch.
It first displays the switch's and NNMi management server's current times. Next, it invokes a
series of commands on the switch and formats these results on the summary page.Click
here for a list of the commands included in this Diagnostic.
Page 419 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
show version
show protocol
show interface summary
show vlans
show cdp
show cdp entry
show cdp neighbors
show log
show stacks
Cisco
Switch
Spanning
Tree
Baseline
Gathers spanning tree protocol and port information from the Cisco switch. The commands
run depend on the device's operating system:
IOS: show spanning-tree brief
CATOS; show spantree
Nortel Switch Diagnostics (Flow Definitions) Provided by NNMi
Name
Description
Nortel Port
Diagnostic
Determines statistics, including rate-limit and usage for a specified port on a Nortel switch.
This Diagnostic detects rate limit, reception and transmission errors. Similar to Cisco
Interface Diagnostic, this flow identifies the following types of errors on the identified port:
Nortel
Route to
Node
Diagnostic
l
FCS errors
l
Undersized packets
l
Oversized packets
l
Collisions
l
Single collisions
l
Multiple collisions
l
Excessive collisions
l
Deferred packets
l
Late collisions
Note: This Diagnostic Flow is not associated with an NNMi incident or node object and can
only be run from Operations Orchestration Central's Flow Library. Before the
Diagnostic runs, you are prompted for access information for the source router and
target device node.
Determines failures of either ping or traceroute to a target node.
Click here for a list of commands included in this Diagnostic
ping target
traceroute target
Page 420 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Name
Description
Nortel
Switch
Baseline
Determines the configuration of a Nortel switch. It first displays the switch's and NNMi
management server's current times. Next, it invokes a series of commands on the switch
and formats the results on the summary page. Click here for a list of commands included in
this Diagnostic
show sys-info
show interface
show logging config
show ssh global
show stack-info
send show rate-limit
send show vlan
Nortel
Switch
Spanning
Tree
Baseline
Gathers spanning tree protocol and port information from the Nortel switch. Click here for a
list of commands included in this Diagnostic
show spanning-tree config
show spanning-tree port
show spanning-tree vlans
Incident Configurations You Might Want to Enable
NNMi enables you to choose whether you want to generate an Incident for any Incident Configuration that
is stored in the NNMi database. To do so you use the Enable attribute for each Incident Configuration.
Note: You can use the Actions menu from the NNMi console to Enable or Disable one or more Incident
Configurations. See "Enable or Disable Configurations" (on page 26) for more information.
By default, not all of the Incident Configurations NNMi provides are enabled.
To determine which Incident Configurations are enabled:
1. Navigate to the Incident Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Incident Configuration.
2. Navigate to the Incident Configuration tab of interest (SNMP Traps, Remote NNM 6.x/7.x Events, or
Management Events).
3. Click the Enable column heading to sort the Incident Configurations according to the Enable
configuration setting.
NNMi displays a
check in the Enabled column for each Incident Configuration that is enabled.
You might want to enable the following Incident Configurations:
"Generate Interface Disabled Incidents" (on page 422)
"Generate Performance Threshold Incidents (HP Network Node Manager iSPI Performance for Metrics
Software)" (on page 422)
Page 421 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Generate Interface Disabled Incidents
By default, NNMi does not generate an incident for interfaces with Administrative Status set to Down. If
you want NNMi to generate incidents for these disabled interfaces, use the following procedures.
To enable the Interface Disabled Management Event incident configuration:
1. Navigate to the Incident Configuration view.
a. In the Workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the Management Events tab.
3. Click the
Open icon in the row that represents the Interface Disabled configuration.
4. Click Enable
.
Generate Card Disabled Incidents
By default, NNMi does not generate an incident for cards withAdministrative Status set to Down. If you
want NNMi to generate incidents for these disabled cards, use the following procedures.
To enable the Card Disabled Management Event incident configuration:
1. Navigate to the Incident Configuration view.
a. In the Workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the Management Events tab.
3. Click the
Open icon in the row that represents the Card Disabled configuration.
4. Click Enable
.
Generate Performance Threshold Incidents (HP Network Node Manager iSPI Performance for Metrics Software)
NNMi can generate incidents related to performance thresholds. NNMi does not generate threshold
incidents until the NNMi administrator configures the performance thresholds and enables the
performance incidents.
To configure NNMi to generate performance threshold incidents:
Prerequisite: Enable performance polling and configure the performance thresholds. See "Configure
Threshold Monitoring for Interfaces (HP Network Node Manager iSPI Performance for Metrics
Software)" (on page 226) for more information.
1. Navigate to the Incident Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Incident Configuration.
2. Select the Management Events tab.
Page 422 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
3. Click the
Open icon in the row representing the configuration you want to enable.
Select from the following threshold incident configurations:
InterfaceInputErrorRateHigh
IntefaceInputDiscardRateHigh
InterfaceInputUtilizationHigh
InterfaceInputUtilizationLow
InterfaceInputUtilizationNone
InterfaceOutputDiscardRateHigh
InterfaceOutputErrorRateHigh
InterfaceOutputUtilizationHigh
InterfaceOutputUtilizationLow
InterfaceOutputUtilizationNone
InterfacePerformanceCritical
InterfacePerformanceWarning
4. Enable the threshold incident by checking Enable
EventConfiguration form.
5. Click
in the Basics group of the Management
Save and Close to save your changes and return to the Incident Configuration form.
6. Repeat steps 3 through 6 for each configuration you want to use.
The HP Network Node Manager iSPI Performance for Metrics Software now records the number and
frequency of threshold related incidents (exceptions). The HP Network Node Manager iSPI Performance
for Metrics Software provides reports to help you establish the root cause of network problems. Access the
HP Network Node Manager iSPI Performance for Metrics Software reports with Actions → Reporting Report Menu in the incident, node, or interface views and forms. (See NNM HP Network Node Manager
iSPI Performance for Metrics Software Actions.)
Manage Incoming SNMP Traps
NNMi provides several tools that enable you to manage the SNMP traps that are sent through the Event
Pipeline and are configured to appear as incidents in the NNMi console. For more information about
NNMI's Event Pipeline, see "About the Event Pipeline" (on page 307).
NNMi uses the following criteria to determine whether it receives or discards incoming traps:
l
If the incoming trap's Source Node object or Source Object (such as card or interface) has not yet been
discovered, NNMi discards the trap by default.
Note: The NNMi administrator can change this behavior using the Trap Handling Settings when
configuring incidents. See "Handle Unresolved Incoming Traps" (on page 428) for additional
information. See also "Configure Network Devices to Send SNMP Notifications to NNMi" (on
page 424).
l
If the Source Node or Source Object of the incoming trap has been discovered by NNMi using
SNMPv3, NNMi accepts incoming traps from SNMPv3, SNMPv2c, or SNMPv1. See "SNMPv3 Settings
Form" for information about configuring SNMPv3 settings.
Page 423 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
l
If the Source Node or Source Object of the incoming trap has been discovered by NNMi using
SNMPv2c or SNMPv1, NNMi discards incoming traps from SNMPv3.
l
NNMi discards traps that have no Incident Configuration or with an Incident Configuration set to
Disabled.
l
If either the Source Node or Source Object has Management Mode set to Not Managed or Out of
Service in the NNMi database, NNMi always discards the incoming trap. See "Understand the Effects
of Setting the Management Mode to Not Managed or Out of Service " (on page 255).
NNMi provides the Management Mode workspace so that you can quickly view lists of all nodes,
interfaces, cards, addresses, or node components that NNMi is not currently discovering or monitoring.
For information about these views:
Note the following:
l
If you want the NNMi management server to forward SNMPv3 traps to other machines in your network
environment, see "Configure NNMi Security Settings for SNMPv3 Trap Forwarding" (on page 295) for
additional configuration steps.
l
If you want the NNMi management server to forward SNMPv2 traps to other machines in your network
environment, see "Configuring Trap Forwarding" (on page 295) for additional configuration steps.
When managing your SNMP Traps consider performing the following tasks:
"Configure Network Devices to Send SNMP Notifications to NNMi" (on page 424)
"Load SNMP Trap Incident Configurations" (on page 425)
"Control which Incoming Traps Are Visible in Incident Views" (on page 427)
"Handle Unresolved Incoming Traps" (on page 428)
"Analyze Trap Information (NNM iSPI NET)" (on page 429)
Related Topics:
"Configuring Trap Forwarding" (on page 295)
Configure Network Devices to Send SNMP Notifications to NNMi
An SNMP notification is a message sent from an SNMP agent (SNMPv1, SNMPv2c, or SNMPv3) on a
network device to notify a network management system of an event on the network device. For example,
an error occurred on the network device and its SNMP agent sent a notification. The notification may either
be an acknowledged inform (SNMP InformRequest) or an unacknowledged trap.
An inform is an acknowledged notification sent from one SNMP agent to another with the expectation of a
reply from the recipient. If no reply is received, the inform message is resent. A trap is a notification sent
from one SNMP agent to another without any expectation of a reply.
Configure SNMP agents in your network environment to send traps to the NNMi management server.
Sometimes SNMP agents are configured with a recheck interval, so the trap might be sent to the NNMi
management server over and over again until the problem is corrected.
The NNMi Causal Engine analyzes these traps and gathers additional information to determine the root
cause. It also provides useful troubleshooting information each time an important SNMP notification is
received, including the following information:
l
The name or address of the node from which the notification came (Source Node)
l
The notification identification (SNMP Object ID)
l
Notification-specific variables (varbinds)
Page 424 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
When configuring the SNMP agent for each network device, configure the trap-forwarding list (or trapdestination list) to include the NNMi management server's fully-qualified hostname or IP address. Refer to
documentation for the SNMP agent for information about how to do this. If the NNMi management server is
included on the trap-forwarding list, NNMi receives notice when something goes wrong (even if the device
does not show up on your NNMi maps).
Note: For an SNMP notification to be processed by NNMi, it must be configured using the NNMi incident
Configuration workspace. Many common SNMP notifications are configured in NNMi by default.
See "Configure SNMP Trap Incidents" (on page 432) and "SNMP Trap Incident Configurations
Provided by NNMi" (on page 313) for more information.
Load SNMP Trap Incident Configurations
NNMi enables you to automatically create or update an Incident Configuration for an SNMP trap using a
MIB file. To load a trap definition using a MIB file, you can use either the command line or NNMi console:
"Load SNMP Trap Incident Configurations from the Command Line" (on page 425)
"Load SNMP Trap Incident Configurations using the Console" (on page 426)
Load SNMP Trap Incident Configurations from the Command Line
The NNMi nnmincidentcfg.ovpl -load script provides a way for you to automatically create or update
an Incident Configuration for an SNMP trap using a MIB file. To load a MIB file, you can use the following
syntax:
If you do not want to enter an NNMi User Name attribute value and an NNMi Password attribute value at
the command line, you can use the nnmsetcmduserpw.ovpl command to specify the valid user name and
password (instead of -u and -p). The credentials set using the nnmsetcmduserpw.ovpl command are
valid for command execution by the same user. See "Set Up Command Line Access" (on page 273) for
more information.
nnmincidentcfg.ovpl -loadTraps <mib_file> -disableAllTraps true|false -u
<NNMiadminUsername> -p <NNMiadminPassword> | -loadMib <mib_file>
Note: See nnmincidentcfg.ovpl for more information, including a complete list of the valid script arguments.
nnmincidentcfg.ovpl Arguments
Argument
Description
-loadTraps
<mib_file>
Used to load the MIB file <mib_file> that you want to use to create or update the
incident configuration for an SNMP trap.
NNMi uses information from the trap definitions (TRAP-TYPES macro) or notification
(NOTIFICATION-TYPES macro) in the MIB file for the required incident configuration.
disableAllTraps
Specifies whether all trap definitions specified using -loadTraps <mib_file> should
be loaded as disabled.
Note: The default value is false. This means that by default all trap definitions
specified in <mib_file> are loaded as enabled. Set this parameter to true to
disable the trap definitions that you are loading.
-u
The NNMi user name. This user must be assigned to at least an NNMi administrator
role.
Note: The user name might be a Principal object stored in the NNMi database or might
Page 425 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Argument
Description
be from your environment's directory service database (depending on NNMi
configuration). See "Configure Sign-In Access" (on page 260) for more
information.
-p
The password associated with the NNMi account.
If you do not want to enter an NNMi User Name attribute value and an NNMi Password
attribute value at the command line, you can use the nnmsetcmduserpw.ovpl
command to specify the valid user name and password (instead of -u and -p). The
credentials set using the nnmsetcmduserpw.ovpl command are valid for command
execution by the same user. See "Set Up Command Line Access" (on page 273) for
more information.
-loadMIB
<mib_file>
Used to load a MIB file for the cases in which the <mib_file> specified with -loadTraps
has dependencies.
For example, to load the MIB file CISCO-VTP_MIB, you might enter the following:
nnmincidentcfg.ovpl -loadTraps "C:\Cisco Mibs\CISCO-VTP-MIB.my"
If the incident is already configured, NNMi performs an update based on the MIB file information. If the
incident is not configured, NNMi creates a new incident configuration entry for the SNMP trap. See
"Configure SNMP Trap Incidents" (on page 432) for information about changing an SNMP trap
configuration.
Load SNMP Trap Incident Configurations using the Console
NNMi enables you to load one or more SNMP Trap Incident Configurations from a MIB file using the NNMi
console.
To load an SNMP Trap Incident Configuration from the NNMi console:
1. Do one of the following:
a. Navigate to the MIB view or form. For example, Select Configuration → Loaded MIBs.
b. Navigate to the MIB Variable view or form. For example, Select Inventory → MIB Variables.
2. Select Tools → Load MIB...
NNMi displays the following information:
n
Unloaded MIBs (user provided) that are stored on the NNMi management server and that were
provided by the NNMi administrator.
n
Unloaded MIBs (NNMi provided) that NNMi has stored on the NNMi management server during
installation.
n
Loaded MIBs that are loaded in the NNMi database.
3. Navigate to the Unloaded MIB view of interest. For example, Unloaded MIBs (User Provided).
4. In the MIB column, find the MIB that contains the trap incidents you want to load. For example,
FLOWMGREST-MIB.
Note: The MIB must support the TRAP-TYPE or NOTIFICATION-TYPE macro.
Page 426 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
5. To view the MIB before loading, in the Actions column, click Display.
NNMi displays the MIB file contents.
6. To load the MIB, in the Actions column, click Load Incident Configuration.
NNMi displays the progress of each trap configuration that is loaded, including the following:
n
The name and location of the MIB file
n
The number of trap incident configurations
n
The name and numeric object identification (OID) of each trap configuration
n
Whether the trap incident configurations successfully loaded
n
Instructions for loading and listing MIB files.
To upload a local MIB file so that it is stored on the NNMi management server and available for loading,
see "Upload MIB Files from the Console" (on page 913).
Control which Incoming Traps Are Visible in Incident Views
You can configure devices in your network environment to send traps to the NNMi management server. To
configure how NNMi handles those traps, use the incident configurations provided by NNMi, create your
own, or both. See "Configure SNMP Trap Incidents" (on page 432) for information about how to configure
SNMP traps as incidents. See "SNMP Trap Incident Configurations Provided by NNMi" (on page 313) for
information about the incident configurations provided by NNMi.
Note: To establish this communication flow, the SNMP agent (SNMPv1, SNMPv2c, or SNMPv3) must be
intentionally configured by the device administrator to send SNMP traps to your NNMi management
server.
After you configure an incident for each SNMP trap you want NNMi to display, NNMi stores your incident
configurations for SNMP traps in the allowedOids.conf file. NNMi uses this file as a positive filter to
identify which traps should appear as incidents.
By default, NNMi enables only the following SNMP Trap incident configurations:
l
CiscoWarmStart
l
CiscoColdStart
l
SNMPWarmStart
l
SNMPColdStart
l
CiscoLinkDown
l
CiscoLinkUp
l
HSRPStateChange
l
IetfVrrpStateChange
l
RcVrrpStateChange
l
SNMPLinkDown
l
SNMPLinkUp
l
RcnAggLinkUp
l
RcAggLinkUp
l
RcnAggLinkDown
Page 427 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
l
RcAggLinkDown
l
RcnSmltIstLinkUp
l
RcSmltIstLinkUp
l
RcnSmltIstLinkDown
l
RcSmltIstLinkDown
See "SNMP Trap Incident Configurations Provided by NNMi" (on page 313) for more information.
Tip: You can configure NNMi to ignore SNMP Traps for objects that are not discovered as part of the NNMi
topology. See "Handle Unresolved Incoming Traps" (on page 428) for more information.
To enable or disable an SNMP trap configuration:
1. Navigate to the Incident Configuration view.
a. In the Workspace navigation panel, select the Configuration workspace.
b. Select the Incident Configuration view.
2. Select the SNMP Traps tab.
3. Click the
Open icon in the row representing the configuration you want to edit.
4. To enable the incident configuration, click Enable
.
5. To disable the incident configuration, clear Enable
.
Related Topics
"Handle Unresolved Incoming Traps" (on page 428)
"Manage the Number of Incoming Incidents" (on page 338)
Handle Unresolved Incoming Traps
Your network environment might be configured to forward SNMP traps to the NNMi management server.
If the trap's source node or source object cannot be matched with any object in the NNMi database, that
trap is considered to be unresolved. Follow the steps in this procedure to specify whether NNMi retains or
discards these traps. For example, if you configure NNMi to discover only devices you specifically list as
seeds, you can decide if you want NNMi to process or ignore traps from any other devices.
See "Manage Incoming SNMP Traps" (on page 423) for more information about the additional criteria
NNMi uses to determine when to receive or discard traps.
To control how NNMi handles unresolved incoming SNMP Traps:
1. Navigate to the Incident Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Incident Configuration.
2. Navigate to the NNMi Trap Handling Settings:
n
If you want NNMi to place unresolved SNMP traps into the NNMi database, clear the Discard
Unresolved SNMP Traps
check box.
Page 428 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Unresolved traps then appear in incident views, but have missing information. For example, the
incident might appear as follows:
o NNMi displays the Source Node as an IP address.
o NNMi displays the Source Object as None.
n
If you want NNMi to ignore any unresolved traps, select the Discard Unresolved SNMP Traps
check box.
Tip: To manage the number of SNMP Traps displayed as incidents, see "Control which Incoming Traps Are
Visible in Incident Views" (on page 427)
Analyze Trap Information (NNM iSPI NET)
NNMi measures the rate of incoming SNMP traps regardless of Incident Configuration, including the
following:
l
Traps from each Node.
l
Traps for each SNMP Object Identifier (OID).
NNMi monitors the incoming SNMP traffic flow to determine whether the number of traps received within a
certain time period exceeds any set threshold. If a threshold is exceeded, NNMi blocks processing of
additional traps until the number of traps falls below the threshold set for each time period.
Note: The NNMi administrator can configure threshold values using the nnmtrapconfig.ovpl script.
When analyzing traps, NNMi looks at both the most common traps as well as the most common Source
Nodes from which the traps are received. NNMi logs this SNMP trap analytics data to the
trapanalytics.0.0.log file.
If NNM iSPI NET is available in your network environment, you can obtain reports about incoming SNMP
traps according to the criteria described in the Trap Analytics Reports table.
Note the following:
l
The time interval and number of Nodes or SNMP OIDs included in the reports and Line Graphs is
based on the numbers configured using the nnmtrapconfig.ovpl script. By default, NNMi uses 5
minutes as the time interval and 10 as the top number of Nodes and SNMP OIDs for which information
is computed.
l
NNMI identifies each trap using its SNMP Object Identifier (OID) number.
l
NNMi enables you to open the following graphs, reports, and forms from a Trap Analytics report:
n
Line Graph of the trap rate for all of the Nodes or SNMP OIDs displayed in the report.
n
Line Graph of the trap rate for a selected Node or SNMP OID.
n
SNMP Trap Incident Configuration form, if any, for an SNMP OID.
n
Source IP Address and Node form for a Node.
Note: The Source Node must be stored in the NNMi database for the links to appear.
n
MIB Variable form, if any, for the selected SNMP OID.
Note: The MIB Variable must be stored in the NNMi database. To add a MIB Variable by loading a
trap, see "Load SNMP Trap Incident Configurations" (on page 425)
Page 429 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
l
When you access a Line Graph from a report, the Line Graph displays an updated real-time data using
the Nodes or SNMP OIDs included in the report. Because the trap rate is constantly changing, the data
in the Line Graph will not match the historical trap numbers displayed in the report.
l
If an SNMP Trap Incident Configuration exists for a trap, NNMi displays the name of the SNMP Trap
Incident Configuration as well as whether the SNMP Trap Incident Configuration is disabled. This
feature is useful when you want to make changes to the Incident Configuration. For example, you might
want to enable or disable the Incident Configuration.
l
NNMi discards traps that have no Incident Configuration or with an Incident Configuration set to
Disabled.
See the Trap Analytics Reports table for more information about the links available from each report.
To access the Trap Analytics reports:
1. Select Tools → Trap Analytics (iSPI NET only).
2. Select the graph or report of interest. from the Trap Analytics submenu.
NNMi displays the selected report (see Trap Analytics Reports).
Trap Analytics Reports
Report
Description
Recent Top
Trap Rate
(by Node)
(Evaluation)
Table view of the Nodes that are most frequently generating traps
during the specified time period.
Links Available
from the Report
Line Graph of the
Nodes that are
most frequently
generating traps.
Recent Top Rate
Traps Received
(by OID) report
Total Traps
Received (by
Node)
Total Traps
Received (by OID)
Line Graph of the
trap rate for the
selected Node.
Source Node form,
if any, for the trap.
Recent Top
Trap Rate
(by OID)
(Evaluation)
Table view of the traps that are most frequently generated during the
specified time period.
Line Graph of the
traps that are most
frequently
generated.
Recent Top Rate
Traps Received
(by Node) report
Total Traps
Received (by
Page 430 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Report
Description
Links Available
from the Report
Node)
Total Traps
Received (by OID)
Line Graph of the
trap rate for the
selected SNMP
OID.
Incident
Configuration
form, if any, for the
selected SNMP
OID.
MIB variable form,
if any, for the MIB
variable that is
associated with
the SNMP OID.
Total Traps
Received
(by Node)
(Evaluation)
Table view of the trap totals since NNMi was last started. This report
is organized by traps per Node.
Line Graph of the
total number of
traps received per
Node since NNMi
was last started.
Total Traps
Received (by OID)
report
Recent Top Trap
Rate (by Node)
Recent Top Trap
Rate (by OID)
Line Graph of a
selected Node's
total traps in real
time.
Source Node form,
if any, for the
selected trap.
Page 431 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Report
Description
Total Traps
Received
(by OID)
(Evaluation)
Table view of the trap totals since NNMi was last started. This report
is organized by traps per SNMP OIDs.
Links Available
from the Report
Line Graph of the
total number of
traps received
since NNMi was
last started.
Total Traps
Received (by
Node) report
Recent Top Trap
Rate (by Node)
Recent Top Trap
Rate (by OID)
Line Graph of the
selected SNMP
OID's total traps in
real time.
Incident
Configuration
form, if any, for the
selected SNMP
OID.
MIB variable form,
if any, for the MIB
variable that is
associated with
the SNMP OID.
Trap
Analysis
Log
(Evaluation)
Log file listing trap information organized by the following criteria:
l
Trap rate in number of traps per second
l
The top 10 addresses that are generating traps
l
The top 10 traps that are being generated
This information is recomputed every 5 minutes as configured in
nnmtrapconfig.ovpl. Scroll to the bottom to see the latest entry.
Note: The NNMi administrator can configure threshold values using
the nnmtrapconfig.ovpl script.
You can also use the nnmtrapdump.ovpl command to extract the
data in which you are most interested from the
trapanalytics.0.0.log file. See the nnmtrapdump.ovpl
Reference Page for more information (Help → Documentation
Library → Reference Pages, in the User Commands category).
Configure SNMP Trap Incidents
Configure incidents that originate from an SNMP trap.
Page 432 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Note: NNMi discards traps that have no Incident Configuration or with an Incident Configuration set to
Disabled.
Tip: You can manage the number of SNMP Traps using either of the following methods: 1) "Manage the
Number of Incoming Incidents" (on page 338) and 2) "Handle Unresolved Incoming Traps" (on page
428).
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure incidents originating from SNMP traps:
1. Navigate to the Incident Configuration form.
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Incident Configuration.
2. Select the SNMP Traps tab.
3. Do one of the following:
n
To create an SNMP trap configuration, click the
n
To edit an SNMP trap configuration, click the
configuration you want to edit, and continue.
n
To delete an SNMP trap configuration, select a row, click the
New icon, and continue.
Open icon in the row representing the
Delete icon.
4. In the SNMP Traps form, provide the required information.
5. Click
Save and Close to save your changes and return to the Incident Configuration form.
The next time that a trap of this type arrives, NNMi creates an associated incident to display in the
appropriate incident views.
SNMP Trap Configuration Form
Note: See "Manage Incoming SNMP Traps" (on page 423) for information about the criteria NNMi uses to
determine when to receive or discard traps.
To configure incidents originating from SNMP traps:
1. Navigate to the Incident Configuration form:
a. From the workspace navigation pane, select the Configuration workspace.
b. Select Incident Configuration.
2. Select the SNMP Traps tab.
3. Do one of the following:
Note: If you want to add or edit an SNMP trap configuration, verify that Enabled
is selected.
n
To add an SNMP trap configuration, click the
New icon, and continue.
n
To edit an SNMP trap configuration, click the
configuration you want to edit, and continue.
Open icon in the row representing the
n
To delete an SNMP trap configuration, select a row, and click the
Page 433 of 1087
Delete icon.
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
4. Make your configuration choices (see table).
5. Click
Save and Close to save your changes and return to the Incident Configuration form.
Tasks for SNMP Trap Configuration
Task
How
"Configure Basic Settings for an SNMP Trap Incident"
(on page 434)
Use the Basics pane of the SNMP Trap
Configuration form.
"Configure Interface Settings for an SNMP Trap Incident" Use the Interface Settings tab of the SNMP
(on page 449)
Trap Configuration form.
"Configure Node Settings for an SNMP Trap Incident"
(on page 485)
Use the Node Settings tab of the SNMP Trap
Configuration form.
"Configure Suppress Settings for an SNMP Trap
Incident"
Use the Suppression tab of the SNMP Trap
Configuration form.
"Configure Enrichment Settings for an SNMP Trap
Incident" (on page 537)
Use the Enrichment tab of the SNMP Trap
Configuration form.
"Configure Dampening Settings for an SNMP Trap
Incident" (on page 540)
Use the Dampen tab of the SNMP Trap
Configuration form.
"Configure Deduplication for an SNMP Trap Incident"
(on page 558)
Use the Deduplication tab of the SNMP Trap
Configuration form.
"Configure Rate (Time Period and Count) for an SNMP
Trap Incident" (on page 563)
Use the Rate tab of the SNMP Trap
Configuration form.
"Configure Actions for an SNMP Trap Incident" (on page
567)
Use the Actions tab of the SNMP Trap
Configuration form.
Configure Basic Settings for an SNMP Trap Incident
The Basics settings for an SNMP Trap Incident specifies general information for an incident configuration,
including the name, severity, and message.
Note the following:
l
NNMi discards traps that have no Incident Configuration or with an Incident Configuration set to
Disabled.
l
When configuring SNMP Trap incidents, if you are using SNMPv3 protocol:
n
You must also configure SNMPv3 communication using the Communication Configuration
workspace. For more information,
n
If you configured SNMPv3 communication, use the Actions → Communication Settings to
determine the SNMPv3 user name that NNMi will use for any node from which you want to receive
Page 434 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
SNMP Trap incidents. Make sure the node is configured with this user name when configuring
SNMP trap incidents. See "Troubleshooting Communication Settings" (on page 107) for more
information.
n
l
If you configured SNMPv1 or SNMPv2 communication, NNMi does not authenticate the community
string for any node from which you want to receive SNMP Trap incidents.
In the Basics group of the SNMP Trap Configuration form, verify that Enable
configuration you want to use.
is selected for each
For information about each SNMP Traps tab:
To configure Basic settings for an SNMP Trap incident:
1. Navigate to the SNMP Trap Configuration form:
a. From the workspace navigation panel, select the Configuration workspace.
b. Select Incident Configuration.
c. Select the SNMP Traps tab.
d. Do one of the following:
i. To create an incident configuration, click the
New icon, and continue.
ii. To edit an incident configuration, click the
Open icon in the row representing the
configuration you want to edit, and continue.
iii. To delete an incident configuration, click the
Delete icon.
2. Configure the required Basic settings (see table ).
3. Click
Save and Close to save your changes and return to the Incident Configuration form.
Basics Attributes for SNMP Trap Configuration
Task
How
"Specify the Incident Configuration Name
(SNMP Trap Incident)" (on page 437)
Use the Basics pane of the SNMP Trap Configuration
form. Specify a name that helps you to identify the
configuration for subsequent use.
"Specify the SNMP Object ID" (on page 437)
Use the Basics pane of the SNMP Trap Configuration
form. NNMi supports SNMPv3, SNMPv2c and SNMPv1
formats.
Specify whether you want to enable this
configuration.
In the Basics group of the SNMP Trap Configuration
form, verify that Enable is selected for each
configuration you want to use.
"Display an SNMP Trap or an NNM 6.x/7.x
Event as a Root Cause Incident" (on page
439)
Use the Basics pane of the SNMP Trap Configuration
form.
"Specify Category and Family Attribute
Values for Organizing Your Incidents (SNMP
Trap Incident)" (on page 439)
Use the Basics pane of the SNMP Trap Configuration
form. You can organize your incidents using Category
and Family.
"Specify the Incident Severity (SNMP Trap
Incident)" (on page 442)
Use the Basics pane of the SNMP Trap Configuration
form. Possible Severity values include: Normal,
Warning, Minor, Major, and Critical.
Page 435 of 1087
Network Node Manager (NNMi 9.00) Online Help: Information for Administrators
Configuring Incidents
Task
How
"Specify Your Incident Message Format
(SNMP Trap Incident)" (on page 442)
Use the Basics pane of the SNMP Trap Configuration
form. The message format determines the message to
be displayed for the incident.
"Specify a Description for Your Incident
Configuration (SNMP Trap Incident)" (on
page 448)
Use the Basics pane of the SNMP Trap Configuration
form. Provide a meaningful description.
Specify an Author for Your Incident
Configuration (SNMP Trap Incident)
Use the Basics pane of the SNMP Trap Configuration
form to indicate who created or last modified the trap.
See Author form for important information.
Caution: If the Author attribute value is HP Network
Node Manager, any changes are at risk of being
overwritten in the future.
Click the
Lookup icon and select
Quick Find to
access the list of existing Author values or click
to create one.
New
After you complete the Basic Configuration for the SNMP trap, you can also choose to configure the
information described in the following table.
Additional Incident Configurations
Task
How
"Configure Interface Settings for
an SNMP Trap Incident" (on page
449)
Select the Interface Settings tab to specify an Interface Group to
which you want your incident configuration to apply.
"Configure Node Settings for an
SNMP Trap Incident" (on page
485)
Select the Node Settings tab to specify a Node Group to which you
want your incident configuration to apply.
"Configure Suppression Settings
for an SNMP Trap Incident" (on
page 524)
Select the Suppression tab to specify the criteria for discarding
incidents that match the selected incident configuration.
"Configure Enrichment Settings for
an SNMP Trap Incident" (on page
537)
Select the Enrichment tab to specify enhancements for the
selected incident configuration.
"Configure Dampening Settings
for an SNMP Trap Incident" (on
page 540)
Select the Dampen tab to specify the time interval that must be me