Using Extended Topology

HP OpenView Network Node Manager
Using Extended Topology
Windows, HP-UX, and Solaris operating systems
Manufacturing Part Number : T2490-90030

July, 2004
© Copyright 2002-2004 Hewlett-Packard Development Company, L.P.

Legal Notices
Warranty.
Hewlett-Packard makes no warranty of any kind with regard to this
manual, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. Hewlett-Packard
shall not be held liable for errors contained herein or direct, indirect,
special, incidental or consequential damages in connection with the
furnishing, performance, or use of this material.
A copy of the specific warranty terms applicable to your Hewlett-Packard
product can be obtained from your local Sales and Service Office.
Restricted Rights Legend.
Use, duplication or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause in DFARS 252.227-7013.
Hewlett-Packard Company
United States of America
Rights for non-DOD U.S. Government Departments and Agencies are as
set forth in FAR 52.227-19(c)(1,2).
Copyright Notices.
©Copyright 2002-2004 Hewlett-Packard Development Company, L.P.
No part of this document may be copied, reproduced, or translated to
another language without the prior written consent of Hewlett-Packard
Company. The information contained in this material is subject to
change without notice.
Contains software from AirMedia, Inc.
© Copyright 1996 AirMedia, Inc.
Trademark Notices.
Java™ is a U.S. trademark of Sun Microsystems, Inc.
This product includes Riversoft NMOS technology. Riversoft® is a
registered trademark of Riversoft Technologies Limited. NMOS™ is a
trademark of Riversoft Technologies Limited. All rights reserved.
2
Netscape™ and Netscape Navigator™ are U.S. trademarks of Netscape
Communications Corporation.
Oracle® is a registered U.S. trademark of Oracle Corporation, Redwood
City, California.
Oracle7™ is a trademark of Oracle Corporation, Redwood City,
California.
OSF/Motif® and Open Software Foundation® are trademarks of Open
Software Foundation in the U.S. and other countries.
UNIX® is a registered trademark of The Open Group.
All other product names are the property of their respective trademark
or service mark holders and are hereby acknowledged.
3
4
Contents
1. Introduction to Extended Topology Functionality
Introducing the Extended Topology Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Extended Topology and the NNM Environment Variables . . . . . . . . . . . . . . . . . . . . 15
Extended Topology and the Web Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Modifying Dynamic View Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Obtaining More Information about Extended Topology . . . . . . . . . . . . . . . . . . . . . . 18
2. Extended Topology Discovery

The Basics of Extended Topology Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
What Extended Topology Discovers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Running Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Automatic Zone Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Manually Configuring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Transferring Information from NNM to Extended Topology . . . . . . . . . . . . . . . . . . . 29
Limiting Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Setting up Dynamic View Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Viewing Discovery Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Understanding Recurring Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Configuring Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Discovering Devices in a Single Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3. Configuring Overlapping Address Domain Discovery

Discovering and Monitoring Nodes by using Overlapping Address Domains . . . . . . . 42
Configuring Extended Topology to Discover and Monitor Overlapping Private Internet
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Understanding OAD View Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Data Collections & Thresholds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4. Problem Diagnosis
Introducing Problem Diagnosis Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Major Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
About Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Starting a Problem Diagnosis View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Installing Remote Probes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Configuring Problem Diagnosis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Linking Servers and Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Configuring Brownouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Configuring Server and Probe Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5
Contents
Configuring Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Other Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Starting and Stopping the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Starting and Stopping a Probe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Limitations and Oddities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Java Oddities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Troubleshooting Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Cleaning Up a Corrupt Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Checking Status of Problem Diagnosis Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Checking Status of Remote Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5. Using the Active Problem Analyzer

Understanding the Basics of the Active Problem Analyzer. . . . . . . . . . . . . . . . . . . . . . 86
Understanding How APA and the netmon Process Cooperate . . . . . . . . . . . . . . . . . . . 89
How APA and the netmon Process Share Information. . . . . . . . . . . . . . . . . . . . . . . . 93
How APA Looks at Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Understanding APA and View Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Understanding APA and HSRP Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Understanding APA, Layer 3 Polling, and Node Status . . . . . . . . . . . . . . . . . . . . . 101
Understanding APA and Event Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Configuration Polling and Interface Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 105
Enabling and Disabling APA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Configuring APA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Understanding APA Polling Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Adjusting APA Polling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Using Topology Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Suppress or Allow APA Status Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Controlling Other APA Polling Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Enable or Disable Global HSRP Group Polling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Enable or Disable HSRP Polling for Devices not Belonging to a Device Class . . . . 128
Enable or Disable SNMP Polling of Devices not Belonging to a Device Class . . . . 130
Enable or Disable ICMP Polling of Devices not Belonging to a Device Class . . . . . 131
Enable or Disable SNMP Polling for Unconnected Switch Ports . . . . . . . . . . . . . . . 133
Disable ICMP Polling for ISDN, SLIP, and Other ifTypes . . . . . . . . . . . . . . . . . . . . 135
Disable APA from Polling Specific Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6
Contents
Disable APA from Using ICMP to Poll Specific Addresses . . . . . . . . . . . . . . . . . . . . 142
Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6. Syslog Integration
Introducing the Syslog Integration Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Syslog Integration Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Configuration Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Default Syslog Trap Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring Syslog Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Prerequisites for Configuring Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Configuring Syslog Integration for NNM Standalone . . . . . . . . . . . . . . . . . . . . . . . 161
Configuring Syslog Integration for OVO with NNM on the Same System . . . . . . . 163
Configuring Syslog Integration for OVO with NNM on Separate Systems. . . . . . . 167
Removing Syslog Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Customizing Message Source Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Overview of Message Source Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Understanding the Template Configuration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Understanding the Syslog to NNM Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
How Syslog to NNM Conditions Function in the NNM Standalone Configuration 181
How Syslog to NNM Templates Function in the OVO with NNM Configuration. . 184
Maintaining Syslog Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Administrative Tasks for NNM Standalone Configurations . . . . . . . . . . . . . . . . . . 190
Administrative Tasks for OVO with NNM Configurations . . . . . . . . . . . . . . . . . . . 191
Troubleshooting Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
System Logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
7. APA and Event Reduction

NNM’s Event Reduction Capabilities When APA Is Enabled . . . . . . . . . . . . . . . . . . . 196
Correlation Composer and APA Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Syslog Integration and APA Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Overview of APA Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
OV_PollerIntermittent Namespace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Multiple LinkDown Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Node Intermittent Status Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Interface Intermittent Status Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Address Intermittent Status Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7
Contents
Connection Intermittent Status Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
OV_PollerLinkDown Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
LinkDown Events and APA Node Status Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
LinkDown Events and APA Connection Status Alarms . . . . . . . . . . . . . . . . . . . . . . 210
OV_CiscoBoard Namespace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
LinkDown and Syslog Down Events with Board Down Events . . . . . . . . . . . . . . . . 212
LinkDown and Syslog Down Events with Syslog Board Down Events . . . . . . . . . . 213
Board Down and Syslog Board Down Events Correlator . . . . . . . . . . . . . . . . . . . . . 214
OV_PollerBoardDown Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Board Down Events with APA Board Failure Alarms . . . . . . . . . . . . . . . . . . . . . . . 216
Syslog Board Down Events with APA Board Failure Alarms . . . . . . . . . . . . . . . . . 217
OV_PollerTrigger Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
APA Poll Trigger Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
OV_PollerTriggerCorr Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
OSPF Adjacency Change Events with APA Root Cause Alarms . . . . . . . . . . . . . . . 224
HSRP State Change Events with HSRP Root Cause Alarms . . . . . . . . . . . . . . . . . 225
Restart-Type Events with APA Node Status Alarms . . . . . . . . . . . . . . . . . . . . . . . . 225
OV_PollerPortAgg Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
LinkDown Events and Syslog Down Events with APA Aggregated Port Alarms . . 227
Syslog Port Aggregation Events with APA Aggregated Port Alarms . . . . . . . . . . . 228
Setting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Disabling APA Correlators and Correlator Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Disabling a Correlator from the Correlator Store. . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Disabling Groups of Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
8. The Advanced Routing Smart Plug-in

What the Advanced Routing Smart Plug-in Discovers . . . . . . . . . . . . . . . . . . . . . . . . 238
Discovering HSRP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Discovering OSPF Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Discovering IPv6 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Running IPv6 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Troubleshooting IPv6 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Properly Displaying Routers not Supporting IPv6 MIBs . . . . . . . . . . . . . . . . . . . . . 243
Properly Displaying IPv6 Nodes with Multiple Addresses . . . . . . . . . . . . . . . . . . . 244
Viewing IPv6 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
8
Contents
Understanding IPv6 Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Supported Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Running OSPF Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Troubleshooting OSPF Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Using the OSPF View to Review Network Configurations. . . . . . . . . . . . . . . . . . . . 254
Running HSRP Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Checking NNM for Correct Handling of HSRP Virtual IP Addresses . . . . . . . . . . 257
HSRP Discovery with Pre-existing NNM Topology . . . . . . . . . . . . . . . . . . . . . . . . . 258
Validating Your Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Using the HSRP View to Diagnose Network Problems . . . . . . . . . . . . . . . . . . . . . . 263
For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
9. Diagnosing Network Problems with Extended Topology

Viewing Extended Topology and NNM Views Using the NNM Alarm Browser . . . . 266
Using the Neighbor View to Diagnose Network Problems . . . . . . . . . . . . . . . . . . . . 266
Using the VLAN View to Diagnose Network Problems . . . . . . . . . . . . . . . . . . . . . . 268
Launching Specific Views or URLs from Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Calculating Detailed Layer 2 and Layer 3 Information for ECS. . . . . . . . . . . . . . . . . 274
10. Maintaining Extended Topology

Maintaining Extended Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Checking for Extended Topology Patch Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Backing Up Extended Topology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Obtaining Supported Device Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Troubleshooting Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Troubleshooting Extended Topology Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
A. Common Zone Configuration Examples

Campus Environment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
General guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Specific guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Possibility 1: Core Devices are Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Possibility 2: Core Devices are Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
B. Successfully Deploying Extended Topology: Practical Deployment Tips

Extended Topology Deployment Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Prediscovery Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
9
Contents
Discovery Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Post Discovery Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
C. Modifying Connections with the Connection Editor

An Overview of the Connection Editor Functionality . . . . . . . . . . . . . . . . . . . . . . . . . 302
Using the Connection Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
The connectionEdits File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Using OQL Inserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
OQL Insert Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Helpful Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Practical Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Other Limitations and Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
D. Controlling Log Files

Types of Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Controlling the Size of Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Switching Logging Off and On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
10
Support
Please visit the HP OpenView web site at:
http://openview.hp.com/
There you will find contact information and details about the products,
services, and support that HP OpenView offers.
The support area of the HP OpenView web site includes:
• Downloadable documentation
• Troubleshooting information
• Patches and updates
• Problem reporting
• Training information
• Support program information
11
12
1 Introduction to Extended
Topology Functionality
Chapter 1 13
Introduction to Extended Topology Functionality
Introducing the Extended Topology Functionality
Introducing the Extended Topology

Functionality
HP OpenView Network Node Manager Advanced Edition’s Extended
Topology functionality (Extended Topology) discovers layer 2 device
information and displays device connectivity. HP OpenView Network
Node Manager Advanced Edition (NNM) is a software application that
discovers and monitors your IP network. See Managing Your Network
with HP OpenView Network Node Manager for more information about
NNM.
NOTE This manual references other information sources when more detailed
information is available. For example, Managing Your Network with HP
OpenView Network Node Manager and the HP OpenView web online
help are two important information sources referenced throughout this
manual.
Extended Topology discovers and displays additional device connectivity

information that you can use to diagnose network problems.
NOTE Extended Topology collects information from devices discovered by NNM.

Extended Topology collects this information from specific MIBs
contained in discovered devices. For information about which devices
Extended Topology supports, see “Obtaining Supported Device
Information” on page 276.
Dynamic Views describes the family of browser-based views whose

content is created as a result of choices you make when you launch the
view, and which continue to provide the most current status information
available.
Extended Topology presents detailed layer 2 network information in
several Dynamic Views: NNM Node view and NNM Neighbor view.
Extended Topology presents ATM information in NNM Node view and
Neighbor view and presents VLAN information in a VLAN view and in
NNM Path view.
14 Chapter 1
See the VLAN View section of the HP OpenView web online help for more
information.
Extended Topology discovers and monitors network domains that use
overlapping private IP addresses. SeeChapter 3, “Configuring
Overlapping Address Domain Discovery,” on page 41 for more
information.
Extended Topology and the NNM Environment

Variables
NNM manuals use directory path names that are independent of the
underlying file structure of the operating system you are using. For each
NNM directory, a single path name is used rather than multiple path
names that vary by system. For example, the path name for the NNM log
file is stated as follows:
• UNIX: $OV_LOG rather than /var/opt/OV/share/log

• Windows:%OV_LOG% rather than \install_dir\log\
The Using Extended Topology manual uses the same path name
convention as the NNM manuals and refers to universal path names
throughout the manual. For example, the path name for the
setupExtTopo.ovpl file is stated as follows:
• UNIX: $OV_BIN rather than /opt/OV/bin

• Windows:%OV_BIN% rather than \install_dir\bin\
You can set up universal path names using environment variables. See
Managing Your Network with HP OpenView Network Node Manager for
details on environment variables and how to set them up for your
environment.
Extended Topology and the Web Browser

Extended Topology views are similar to NNM’s Dynamic Views, such as
Node view and Neighbor view.
You must use a supported web browser and have the correct Java Plug-in
(JPI) installed to access Extended Topology views. For information about
supported web browsers and JPI versions see “Supported
Configurations” in the Release Notes.
Chapter 1 15
If the Extended Topology installation program can’t find a web browser

on a UNIX host system, it allows the installer to specify the web browser
location. This is the browser that launches the NNM web interface and
Extended Topology views. Edit the following file if you want to change
the browser location after you install NNM and Extended Topology.
• UNIX: $OV_CONF/ovweb.conf
For more information about the ovweb.conf file, see the ovweb.conf
manpage).
Before you can access Extended Topology views, you must wait for a
complete Extended Topology discovery to occur. For information about
running Extended Topology Discovery, see “Running Extended Topology
Discovery” on page 23.
Accessing Dynamic Views

After Extended Topology completes a discovery, you can access the
VLANs view, Node view, Path view, and Neighbor view in the following
ways:
• From the NNM menu, Tools:Views.

• From the Network Presenter menu, Tools:Views.
• From the Launcher, Tools tab.
Home Base is a launching point for Dynamic Views. See Figure 1-1 on
page 17 for an example of Home Base. In addition to launching views
from Home Base, you can select tabs that cause Home Base to display
additional information about your network. You can access Home Base
from your browser using the following URL:
http://hostname:7510
16 Chapter 1
Figure 1-1 NNM’s Home Base
You can also access NNM Dynamic Views from the Alarm Browser:
1. Select an alarm from the Alarm Browser.

2. Select Actions:Views using the Alarm Browser menus.
3. Select any of the NNM or Extended Topology views located in the
Views menu.
NOTE Dynamic Views launched from Home Base contain tools such as Ping
and Trace Route that originate from the browser’s system, not the
management station. Access controls and security restrictions are based
on the rules that apply to the system and user of the browser.
Chapter 1 17
You can configure the Alarm Browser to access any view or URL from a
specific event. You cannot configure the web-based Alarm Browser to
access any view or URL from a specific event. See “Launching Specific
Views or URLs from Alarms” on page 272.
Modifying Dynamic View Menus

Application developers and end-users can modify Dynamic View menus.
See the menusettings.xml (4) reference page in NNM’s online help (or
the UNIX manpage) for more information.
Obtaining More Information about Extended

Topology
You can view information from the HP OpenView web online help in the
following way:
• To view the HP OpenView web online help, select the ? icon (see
Figure 1-2) in the upper right corner of any of the Dynamic Views.
Figure 1-2 Selecting the HP OpenView Web Online Help
• There are several ways of interacting with Dynamic Views. See the
Interacting with Views section of the HP OpenView web online help.
• There are several visual cues that give you more information about
Dynamic Views. See the Using Visual Cues in Views section of the
HP OpenView web online help.
You can view the Using Extended Topology manual and the NNM
Release Notes in the following ways:
• View the NNM Release Notes from NNM: Help->NNM->Release

Notes.
• View this manual from NNM: Help->Online Manuals->Using
Extended Topology.
18 Chapter 1
2 Extended Topology Discovery
Chapter 2 19
Extended Topology Discovery
The Basics of Extended Topology Discovery

Extended Topology layer 2, VLAN, ATM, and overlapping address
domain (OAD) discovery is different from NNM discovery. Rather than
incrementally discovering new nodes over time, you configure Extended
Topology to periodically discover network information. See “Configuring
the Extended Topology Discovery Process” on page 36 for more
information.
In contrast, when you first install NNM and start the NNM background
processes, all IP and layer 2 devices (devices that support bridge,
repeater, and MAU MIBs) on your network are automatically discovered
and mapped out. The discovery and mapping process may take several
hours, or even overnight, to discover all the devices on your network.
Over time, NNM continues to discover new nodes.
After you install NNM and Extended Topology, you must enable
Extended Topology before the initial Extended Topology discovery will
start. In a very large environment, Extended Topology discovery can take
up to several hours. Completing a good NNM discovery prior to enabling
Extended Topology can reduce the discovery time. See Managing Your
Network with HP OpenView Network Node Manager for more
information about NNM discovery.
In larger environments, Extended Topology divides your IPv4 network
into discovery zones to reduce the amount of time to complete an
Extended Topology discovery. See “Running Extended Topology
Discovery” on page 23 for more information about configuring zones.
NOTE Extended Topology collects detailed information from devices whose

existence was discovered by NNM. Extended Topology collects this
information from specific MIBs contained in discovered devices. For
information about which devices Extended Topology supports, see
“Obtaining Supported Device Information” on page 276.
20 Chapter 2
What Extended Topology Discovers

Extended Topology discovers information about layer 2 device
interconnections, VLANs, and ATM connectivity. You can configure
Extended Topology to monitor network domains that use overlapping
private IP addresses.
Discovering Layer 2 Information

Extended Topology discovers layer 2 connection information and uses
this information to map managed nodes and their neighboring port
relationships. The result is a more accurate view of your network.
Discovering VLAN Information

Extended Topology discovers and displays VLAN information from
managed devices. See “Accessing Dynamic Views” on page 16 or the HP
OpenView web online help for more information on how to view this
information from the Extended Topology user interface.
Discovering Board and Port Information on Cisco Devices

Extended Topology discovers and displays Cisco board and port
information for devices that support the CISCO-C2900-MIB,
CISCO-STACK-MIB, or CISCO-RHINO-MIB. This includes the board,
interface, and address information contained in supported Cisco devices.
To view this information, double-click on a Cisco device from one of
NNM’s Dynamic Views.
Discovering Multiple Links Between Two Devices

When multiple links between two devices behave as one logical link,
different vendors call it trunking, port aggregating, or link aggregating.
Each device that has a few ports in that configuration is said to have a
trunk or port aggregation, depending on the vendor and technology used.
For example, Cisco Systems, Inc., uses the term port aggregation for
multiple links that act as one logical link. In addition, Cisco uses the
term trunk to mean a single link between two switches or switch-routers
that carries the traffic of multiple VLANs.
Extended Topology discovers and displays this information as an
aggregated-ports symbol (circle with internal lines) for Cisco devices, or
redundant links symbol (circle with internal diamond) for other devices.
Chapter 2 21
Discovering ATM information

Extended Topology discovers ATM information such as Virtual Path
Identifier (VPI) and Virtual Channel Identifier (VCI). You can view this
information by resting your mouse pointer over an interface that
supports ATM.
Discovering Overlapping Address Domain Information

Extended Topology can monitor multiple network domains that contain
overlapping addresses from the private internet address space. This
situation occurs when you manage multiple private IP address domains
from outside of their gateways, and some of the addresses overlap. Before
you can use the Extended Topology component to manage your
overlapping IP addresses, you need to provide it with some additional
information. See Chapter 3, “Configuring Overlapping Address Domain
Discovery,” on page 41 for more information.
Discovering and Distributing Extended Topology Information

Extended Topology only discovers information from locally managed
nodes and does not pass Extended Topology information from a collection
station to a management station. To open Dynamic Views that include
information from the extended topology, you need to point your web
browsers to an object’s primary collection station.
22 Chapter 2
Running Extended Topology Discovery

After you install Extended Topology, you must run the following script to
enable it:
• Windows: %OV_BIN%\setupExtTopo.ovpl
• UNIX: $OV_BIN/setupExtTopo.ovpl
This command initializes Extended Topology as follows:
• It determines the protocols your environment supports and decides

what information it needs to discover.
• It checks the system kernel parameters and tells you if you need to
make any system modifications.
• It asks you whether you want to discover information about certain
protocols.
• It asks you to set up your initial Dynamic Views password. It is
recommended that you do not use the root or Administrator
password, as that could grant excessive authority to the person who
is merely responsible for Extended Topology configuration.
• It determines the number of nodes NNM is managing.
• In larger environments, it can divide the IPv4 devices discovered by
NNM into smaller discovery zones. See “Automatic Zone
Configuration” on page 24 for more information.
Zone-based discovery consumes fewer computer resources, resulting in
potentially much faster network discovery. Zones can be thought of as
"islands of connectivity", which are discovered independently and later
brought together through their edge connections.
When possible, Extended Topology immediately proceeds with its first
discovery without recommending zone configuration.
Chapter 2 23
Automatic Zone Configuration

When you run the setupExtTopo.ovpl script, Extended Topology
determines the need for using discovery zones, and can automatically
configure these zones for larger environments. If you choose to have
Extended Topology configure these zones for you, make sure you follow
the displayed instructions carefully.
Use the following procedure to have Extended Topology automatically
configure your zones. This procedure also tells you how to test the zones
prior to running your first discovery:
1. Open the Configure Extended Topology GUI using the NNM

Options: Extended Topology Configuration menu or select the
Discovery Status tab from Home Base, then select [Extended
Topology Configuration].
2. Select the Discovery Zones tab.
3. If you already ran the setupExtTopo.ovpl script and asked
Extended Topology to automatically configure zones for you, do not
reconfigure your zones at this time. However, test your zones prior to
starting a discovery. If you want Extended Topology to automatically
configure zones for you, select [Configure Zones Automatically].
4. Select [Test All Zones] to test all of the zones, display any
warnings, and view any suggested remedies. If necessary, manually
reconfigure the new zones to resolve these warning messages.
5. Be sure to select [Apply] to activate any manual changes.
Once these zones are successfully configured, select [Initiate Full
Discovery Now] or run the following script to start the discovery:
• Windows: %OV_BIN%\etrestart.ovpl
• UNIX: $OV_BIN/etrestart.ovpl
NOTE The etrestart.ovpl script will not interrupt a discovery in progress

or another etrestart.ovpl script that was executed earlier, unless
you use the etrestart.ovpl -force script. See the etrestart.ovpl
reference page (or the UNIX manpage) for more information.
24 Chapter 2
NOTE Once you run the setupExtTopo.ovpl script, you can have Extended
Topology automatically configure discovery zones at your request. Use
this automatic zone configuration feature only after completing a
successful NNM discovery.
If you request that Extended Topology configure zones automatically at a

later time, you will overwrite any existing zone configuration
information. To automatically configure your zones, use the following
procedure:
1. From Home Base, select the Discovery Status tab.

2. Select [Extended Topology Configuration].
4. Select [Configure Zones Automatically] and follow the
instructions.
5. Once Extended Topology completes the automatic configuration
process, it displays any warning messages. You can also select [Test
All Zones] to test all of the zones, display any warnings, and view
any suggested remedies. If necessary, manually reconfigure the new
zones to resolve these warning messages.
6. Be sure to select [Apply] to activate any manual changes.
Verifying and Modifying Your Zone Configuration

If the following node changes occur after you configure your zones, you
may need to adjust your new zones:
• NNM discovers new nodes.

• You manage existing nodes that were previously unmanaged.
Extended Topology could place these nodes in the default zone or in an
existing zone if the IP address matches one of the zone’s subnet
wildcards. Use the following techniques to decide if Extended Topology
placed nodes into incorrect zones:
• Check the output for nodes that incorrectly appear in the default
zone by using the following procedure:
Chapter 2 25

Options: Extended Topology Configuration menu or select
the Discovery Status tab from Home Base, then select
[Extended Topology Configuration].
3. Select [Test All Zones] and review the displayed information.
• Check your topology for nodes that are missing connections.
Once you identify these nodes, you can manually place these nodes into
the right zones or run another automatic zone configuration. “Manually
Configuring Zones,” for more information.
Manually Configuring Zones

In most cases, Extended Topology configures zones for you. However, in
certain circumstances you may want to manually adjust your zone
configuration to try and reduce Extended Topology’s discovery time.
There is another reason you may want to manually adjust your zone
configuration. Suppose Extended Topology displayed warnings when you
selected [Test All Zones]. To remedy these warnings, you may need to
manually adjust the zone configuration.
A good strategy for defining zones is to categorize your network devices
by geography, such as by city, state, or building.
NOTE When defining your zones, do not separate switches that are directly
connected together within a subnet.
To manually organize your devices into zones, use the following

procedure:

Options: Extended Topology Configuration menu or select the
Discovery Status tab from Home Base, then select [Extended
Topology Configuration].
26 Chapter 2
3. Organize your devices into zones. You may need to calibrate your
zones as outlined in this procedure. See Appendix A, “Common Zone
Configuration Examples,” on page 281 for more information.
• Organize zones with fewer nodes when these nodes contain many
interfaces. An example of this would be a network that contains a
high quantity of switches housing many ports.
• Organize zones with more nodes when these nodes contain fewer
interfaces. An example of this would be a network that contains a
low quantity of switches housing few ports.
4. You can limit Extended Topology discovery to only those devices you
specify in zones. To do this, select the check box that excludes nodes
that are not included in any of the zones you configure.
NOTE When the Extended Topology discovery process begins, NNM

transfers its node information to Extended Topology. Extended
Topology includes these nodes in its discovery process. If you assign
nodes to discovery zones, there may be a subset of the nodes
transferred from NNM that aren’t included in any zone. Extended
Topology automatically assigns these remaining nodes to a default
zone. Select this check box to stop Extended Topology from
discovering these nodes.
You can also limit your discovery with the bridge.noDiscover file.
Devices specified there are not discovered regardless of how you
configure your zones. See “Limiting Extended Topology Discovery” on
page 32 for more information.
5. In the Zone:Administration text box you can specify any hostname

that your DNS server can resolve to an IP address, or directly specify
any node’s IP address. Separate entries with a semicolon. You can
also use the following wildcard symbols:
• Asterisk: Use an asterisk to represent any number of characters

up to the next period:
*.corp.com matches pc.corp.com or ws.corp.com.
pc.*.com matches pc.corp.com or pc.location.com.
Chapter 2 27
*.* matches corp.com or pc.com, but not pc.corp.com.

The * in 10.*.1.3 matches any number.
• Question mark: Use to match a single character:
pc.c?.com matches pc.ca.com, pc.cb.com, or pc.cc.com, but
does not match pc.cal.com or pc.c.com.
pc.???.com matches pc.abc.com, pc.bcd.com, or pc.cde.com,
but does not match pc.ab.com or pc.abcd.com.
• Brackets: Use to match single characters, characters within a
range, or characters not within a range:
[bcf]an.corp.com matches ban.corp.com, can.corp.com, or
fan.corp.com, but does not match dan.corp.com or
lan.corp.com.
[b-d]an.corp.com matches ban.corp.com, can.corp.com, or
dan.corp.com, but does not match fan.corp.com, an.corp.com, or
clan.copr.com.
[!d-z]an.corp.com restricts the selection to aan.corp.com,
ban.corp.com, or can.corp.com.
• Dash: Specify a range of IP addresses.
10.2.1-3.1 represents 10.2.1.1, 10.2.2.1, or 10.2.3.1
6. Select [Add New Zone] to move each new zone into the Current
Zones area of the Extended Topology Configuration screen.
Select a zone, then select [Add to Zone] to add more addresses to a
specific zone. You can also use [Delete] and [Replace] to help you
manage your zones.
7. Select [Test All Zones] to test your zones. This test will check
your zone configuration and may recommend configuration changes.
8. Select [Apply] to save your changes.
9. Once these zones are successfully configured, select [Initiate Full
Discovery Now] or execute, as Administrator or root, the following
script to start a discovery:
• Windows:%OV_BIN%\etrestart.ovpl
28 Chapter 2
NOTE After you move devices between or among zones, you should initiate
a full Extended Topology discovery. If you add new devices to or
delete devices from a single zone, you can save time by initiating an
Extended Topology discovery on that single zone.
10. You can check the amount of time Extended Topology spends
discovering your zones by running the ovstatus -v ovet_disco
command. If the discovery time of any of your zones is abnormally
long when compared to that of other zones, do one or both of the
following:
• Add a new zone and move some of the devices from the problem
zone into the new zone.
• Move some of the devices from the problem zone into one or more
of the existing zones that are being discovered faster.
Once these zones are successfully configured, select [Initiate Full
Discovery Now] or execute, as Administrator or root, the
etrestart.ovpl script to start a new Extended Topology discovery.
NOTE Once Extended Topology completes a discovery with the new zone
configuration, you should check the discovery results to make sure your
zones are configured correctly. See “Verifying and Modifying Your Zone
Configuration” on page 25.
Transferring Information from NNM to Extended

Topology
Extended Topology uses NNM data to speed up discovery. When a new
discovery begins, Extended Topology starts background processes that
retrieve data from NNM about the devices NNM is actively managing.
Extended Topology discovers information from these devices if they
respond to SNMP requests.
For a device not responding to SNMP requests, Extended Topology
creates a node and a local interface for that node using NNM data. This
node appears in the Extended Topology views, but may contain an
incomplete set of attributes and connectivity. To identify an unresponsive
Chapter 2 29
node, move your mouse over the node in one of the Extended Topology
views. Extended Topology will display a message about SNMP access
problems with the node.
To enable Extended Topology, run the following script and follow the
instructions:
• Windows: %OV_BIN%\setupExtTopo.ovpl
• UNIX: $OV_BIN/setupExtTopo.ovpl
After you enable Extended Topology with the setupExtTopo.ovpl
script, you will only need to run this command again if you want to
enable or disable certain protocols. For more information about the
setupExtTopo.ovpl script, see the setupExtTopo.ovpl reference page in
NNM’s online help (or the UNIX manpage.
The following information is copied from NNM to Extended Topology and
used by several Extended Topology processes. See Figure 2-1 on page 31
for a graphical illustration.
• NNM IP address and hostname information.

• NNM ARP cache information.
• NNM SNMP community string information.For more information
about NNM and Extended Topology community names, see the
ovsnmp.conf_db reference page in NNM’s online help (or the UNIX
manpage).
• NNM SNMP port information.
NOTE Extended Topology uses the information it receives from NNM to

calculate the number of nodes it may discover. Extended Topology
notifies you when the number of discovered nodes exceeds the number of
nodes it is licensed for. Extended Topology may discover additional
interfaces after receiving information from NNM, however it does not
count these interfaces as discovered nodes for licensing purposes.
Use the Options:Configuration-->SNMP Configuration menu to

change device community string information in NNM. Extended
Topology applies SNMP community string configuration changes during
30 Chapter 2
the next discovery cycle. For more information about changing device
community string information, see the xnmsnmpconf reference page in
NNM’s online help (or the UNIX manpage).
If you need Extended Topology to apply new SNMP community string
changes immediately and run a new Extended Topology discovery, go to
Home Base and use the following procedure:
1. Select the Discovery Status tab

2. Select [Extended Topology Configuration]
3. Select [Initiate Full Discovery Now]
You can also execute, as Administrator or root, the following script to
run a new Extended Topology discovery:
For more information about the etrestart.ovpl script, see the
etrestart.ovpl reference page in NNM’s online help (or the UNIX
manpage).
Figure 2-1 NNM to Extended Topology Information Transfer
NNM automatically NNM seeds the

discovers and stores Extended Topology
device information periodic discovery
setupExtTopo.ovpl
script starts
information transfer
to Extended Topology
Extended Topology
receives host, ARP,
NNM databases NNM community name, and
information SNMP port information
from NNM.
Chapter 2 31
Limiting Extended Topology Discovery

You can exclude devices from Extended Topology discovery by creating
an Extended Topology Discovery Exclusion List.
Creating the Extended Topology Discovery Exclusion List

Extended Topology limits the breadth of discovery according to the
contents of the following file:
• Windows: %OV_CONF%\nnmet\bridge.noDiscover
• UNIX: $OV_CONF/nnmet/bridge.noDiscover
You enter NNM filter names, IP addresses and wildcards into the
bridge.noDiscover file that you want the discovery process to ignore.
Here are a few examples of valid bridge.noDiscover file entries:
• 10.2.112.86 # Exclude this IP address from discovery.

• *.*.*.* # Exclude all nodes from discovery.
• 10.2.*.* # Exclude all IP addresses from 10.2.0.0 to 10.2.255.255.
• 10.2.0-2.* # Excludes all nodes from 10.2.0.0 to 10.2.2.255.
• Routers #Excludes all nodes matching the NNM filter Routers.
Do the following to create the bridge.noDiscover file:
1. As Administrator or root, create the bridge.noDiscover file.

2. Add NNM filter names, IP addresses or wildcards you want excluded
by Extended Topology discovery. Enter one NNM filter name, IP
address or wildcard per line.
3. Run a new Extended Topology discovery.
For more information about the Extended Topology Discovery Exclusion
List and the bridge.noDiscover file, see the bridge.noDiscover
reference page in NNM’s online help (or the UNIX manpage).
Setting up Dynamic View Security

During Extended Topology setup, you were prompted to enter an
Administrator login and password. To configure additional user roles and
passwords, edit the following file:
32 Chapter 2
• Windows:
%OV_AS%\webapps\topology\WEB-INF\dynamicViewsUsers.xml
• UNIX:
$OV_AS/webapps/topology/WEB-INF/dynamicViewsUsers.xml
This file contains examples of how to set up various user roles. You can
create an operator role that has access to all of the Dynamic Views, but
cannot access any of the configuration tools. See the
DynamicViewsUsers.xml reference page in NNM’s online help (or the
UNIX manpage) for more information.
If non-ASCII characters are added to XML files, you must preserve the
UTF-8 codeset for these characters.
NOTE The Windows Notepad editor allows files to be saved in the UTF-8 code
set. On many UNIX platforms, the iconv command can be used to
translate from Shift JIS (or any other code set) into UTF-8 to make
editing in a non-UTF-8 codeset simpler.
For more detailed information on setting up passwords, including how to

use MD5 encryption, look for additional instructions contained in the
following file:
• Windows: %OV_AS%\webapps\topology\WEB-INF\web.xml
• UNIX: $OV_AS/webapps/topology/WEB-INF/web.xml
Viewing Discovery Status

You must wait for Extended Topology to complete an initial discovery
before using Extended Topology views. To view Extended Topology
discovery status, use the following procedure:
1. Point your browser to Home Base

The discovery status is normally updated quite often, but there can be
long periods, potentially many hours, where the progress bar does not
change. This is due to the duration of some processing steps and the way
progress is measured. It does not reflect a problem with discovery.
Chapter 2 33
While Extended Topology discovery is in progress, the activity indicator

moves to indicate that everything is proceeding normally. The activity
indicator usually moves every few seconds, but you should keep in mind
that it may pause during lengthy internal operations. Ordinarily, a pause
of this kind will be fifteen minutes or less.
However, if the activity indicator is stationary for too long, such as an
hour or more, Extended Topology discovery may have stalled. You can
use the discovery status time stamp in the text area to find the time of
the most recent update.
You can use the following command to display the statuses of each of the
Extended Topology discovery processes.
• Windows: %OV_BIN%\ovstatus -c
• UNIX: $OV_BIN/ovstatus -c
Many Extended Topology processes only run during discovery. After
Extended Topology completes its discovery, these processes
automatically exit. The following process status output shows the output
of the ovstatus -c command for those processes:
ovet_processname - NOT_RUNNING Exited and awaiting next discovery. Exit (0).
Extended Topology automatically restarts its discovery processes, and
begins another discovery, when it reaches or exceeds its discovery
thresholds. You can use the Extended Topology Configuration GUI to
modify these discovery thresholds. To open the Extended Topology
Configuration GUI, use the NNM Options: Extended Topology
Configuration menu or select the Discovery Status tab from Home
Base, then select the Configure Topology tab.
For more information about troubleshooting Extended Topology
discovery, see “Troubleshooting Extended Topology Discovery” on
page 277.
Understanding Recurring Discovery

The Extended Topology model of recurring discovery differs from the
continuous discovery present in NNM. Extended Topology captures data
about your network as it exists during the most recent discovery cycle, or
the most recent previous discovery cycles. It does not update the data
between discovery cycles.
34 Chapter 2
This means that only the layer 2 connections that exist during Extended
Topology discoveries get recorded. In addition, device information (such
as VLAN, port aggregation, and ATM data) is gathered only from devices
that are accessible during the Extended Topology discoveries. An
“accessible” device responds to SNMP requests from NNM. For this to
happen, NNM must be configured to use the correct SNMP
GET-Community name for the device.
Situations may arise that prevent a previously discovered device from
responding with device information during later discovery cycles. When
a situation like this arises, Extended Topology retains data about the
previously discovered, but unresponsive device for recent discovery
cycles.
In contrast, suppose a specific device becomes unresponsive, and
continues to be unresponsive during several consecutive discovery cycles.
The device and its information are no longer shown in NNM’s Dynamic
Views.
Post-discovery changes in the network are not dynamically reflected in
the data that Extended Topology provides. They instead get incorporated
during the next discovery cycle. You should be aware of this behavior,
and some of its implications. For example:
• If a device was inaccessible during recent Extended Topology

discoveries, but responded with device information during the most
recent discovery cycle, a VLAN view will display VLAN information
for it.
• If a device became inaccessible during some past Extended Topology
discovery, and continued to be unresponsive during several
consecutive discovery cycles, a VLAN view will not display the device
or VLAN information about the device.
• A Neighbor view will omit a neighboring device that happened to be
inaccessible during several consecutive discovery cycles.
This list is not comprehensive, but gives you a sense of how periodic
discovery can affect the data you observe later.
You can modify Extended Topology’s default discovery options to meet
your specific needs using information from this list. See “Configuring the
Extended Topology Discovery Process” on page 36 for more information.
Chapter 2 35
Configuring Extended Topology Discovery

In smaller environments, Extended Topology begins discovering network
information after you run the setupExtTopo.ovpl script. Extended
Topology defaults to running a discovery once a default number of NNM
topology changes occur.
Configuring the Extended Topology Discovery Process

To modify Extended Topology discovery options, use the NNM menu
Options:Extended Topology Configuration or select the Discovery
Status tab from Home Base, then select the Configure Extended
Topology tab. You have several configuration options. You can configure
Extended Topology discovery behavior if you select the Discovery
Behavior tab. This allows you to do the following:
• Initiate a new discovery every time Extended Topology is restarted.

• Enable or disable Extended Topology recurring discovery.
• Begin a new discovery after NNM detects a number of topology
changes. The number of topology changes includes layer 3 discovery
information from NNM.
• Schedule a new discovery daily or weekly.
• Immediately begin a new discovery by selecting [Initiate Full
Discovery Now].
Make sure you select [Apply]to save your changes.
NOTE Suppose you configure Extended Topology to initiate a new discovery

every time Extended Topology is restarted. Then every time you run, as
Administrator or root, the following command, it initiates a new
Extended Topology discovery.
• Windows: %OV_BIN%\ovstart
• UNIX: $OV_BIN/ovstart
Use caution when using the ovstart command, as it restarts all NNM and
Extended Topology processes. For more information about the ovstart
command, see the ovstart reference page in NNM’s online help (or the
UNIX manpage).
36 Chapter 2
After modifying Extended Topology discovery options, you can apply

these modifications and start a new discovery by doing one of the
following tasks:
• Run, as Root or Administrator, the following script:
— Windows: %OV_BIN%\etrestart.ovpl
— UNIX: $OV_BIN/etrestart.ovpl
• Go to Home Base and complete the following procedure.

3. Select [Initiate Full Discovery Now]
• If you add new devices to a specific zone, complete the following
procedure:
1. Go to Home Base
4. Select the [Discovery Zones] tab
5. Select the zone you modified
6. Select [Discover Zone]
NOTE The [Discover Zones] button causes Extended Topology to run a new
discovery, but only on the devices in one specific zone. This is useful if
you have added or deleted nodes in that one zone. However, if you know
of changes in multiple zones (such as when you have relocated a node
from one zone to another), you should run a full discovery.
You can display the process statuses by executing the following

command:
• Windows: %OV_BIN%\ovstatus -c
• UNIX: $OV_BIN/ovstatus -c
Chapter 2 37
If you restart Extended Topology processes and you do not have

Extended Topology configured to run a new discovery every time you
restart it, the ovstatus -c command output will look as follows:
ovet_processname 5621 RUNNING Discovery Completed: date and time of last
discovery.
The RUNNING portion of the message indicates a state of readiness for

discovery processes. A new discovery does not occur until Extended
Topology meets the discovery configuration parameters you set in the
Extended Topology Configuration GUI, you select [Initiate Full
Discovery Now], or you execute, as Administrator or root, the
etrestart.ovpl script.
For more information about the etrestart.ovpl script, see the
etrestart.ovpl reference page (or the UNIX manpage). For more
information about Extended Topology configuration see the HP
OpenView web online help.
Discovering Devices in a Single Zone

If Extended Topology has already successfully completed a full discovery,
you can rediscover an individual zone without initiating another full
discovery.
Suppose you add new devices to a single zone. You can save time by
initiating an Extended Topology discovery on that single zone. To do this,
follow these instructions:

3. Select the Discovery Zones tab. If you configured Overlapping
Address Domains, you can also select the Overlapping Address
Domain tab and select a zone from that view.
4. Select the zone you want to discover.
5. Select [Discover Zone]to initiate a discovery of the selected zone.
38 Chapter 2
NOTE The [Discover Zones] button causes Extended Topology to run a new
discovery, but only on the devices in one specific zone. This is useful if
you have added or deleted nodes in that one zone. However, if you know
of changes in multiple zones (such as when you have relocated a node
from one zone to another), you should run a full discovery.
After you initiate your discovery, you can monitor the status of your
discovery. See “Viewing Discovery Status” on page 33 for more
information.
Chapter 2 39
40 Chapter 2
3 Configuring Overlapping
Address Domain Discovery
Chapter 3 41
Configuring Overlapping Address Domain Discovery
Discovering and Monitoring Nodes by using Overlapping Address Domains
Discovering and Monitoring Nodes by using

Overlapping Address Domains
The need to conserve IPv4 addresses led to the development and
deployment of IP addresses in the private internet address space. To
understand details about the private internet address space, see
RFC1918.
As the use of the private address space increased, so did demand for
Internet access to computers configured with private IP addresses. Static
network address translation (or, "static NAT") was developed to answer
this demand. Static NAT takes place on the gateway between the private
address domain and the Internet. A gateway configured with static NAT
maps public IP addresses (or, "management IP addresses") to computers
in the private address domain. Those computers, still configured with
private IP addresses, are then directly accessible over the Internet via
the static NAT gateway.
When using NNM to manage multiple domains that use private IP
addresses, it often discovers duplicate private IP addresses.You need to
use the Extended Topology features of NNM Advanced Edition to
manage network domains that have overlapping private internet
addresses.
You can use Extended Topology to distinguish these overlapping
addresses by configuring each address group into an OAD (overlapping
address domain). A single OAD is a set of IPv4 addresses that are static,
do not overlap, and are directly routable without manipulation of the
IPv4 header.
Figure 3-1 on page 43 shows an example of Extended Topology managing
two private address domains from a point outside either one. Suppose
the IP addresses in OAD A and OAD B overlap. You can configure
Extended Topology to differentiate addresses from the two overlapping
address domains.
If there is a firewall between the NNM management station and any
nodes tied to a specific OAD, you must configure this firewall to pass
ICMP (port 7), SNMP (port 161), and SNMPTRAP (port 162) packets
between the management station and the managed nodes. If you want to
log on to any OAD nodes (telnet) using Dynamic Views from the
management station, you will need to open port 23 as well. This minimal
42 Chapter 3
relaxation of the firewall is required to support network management

through it. By restricting the communications to the management
station only, there is virtually no loss of security.
Figure 3-1 Overlapping Address Domains
NNM Management
Station (Extended
Topology Functionality)
Network
Gateway A Gateway B
OAD A OAD B
Configuring Extended Topology to Discover and

Monitor Overlapping Private Internet Addresses
Before you can use Extended Topology to monitor your overlapping
private IP addresses, you need to provide the information discussed
below.
Providing Extended Topology with OAD Information

A key concept of monitoring overlapping private IP addresses is
understanding the OAD. The OAD denotes a set of unique, private IP
addresses. For example an OAD might represent the private IP
addresses of a small business, specific department, or a specific
workgroup in a large company.
1. For each OAD that you define, you need to create a separate
directory beneath the following directory:
Chapter 3 43
• Windows: %OV_CONF%\nnmet\dupip
• UNIX: $OV_CONF/nnmet/dupip
There is no specific naming convention, so you can choose a friendly
name for each directory. As an example, suppose you have a group of
private IP addresses in an OAD for a store called My Shop. You
would create one of the following directories for this OAD:
• Windows:%OV_CONF%\nnmet\dupip\myShopDomain
• UNIX: $OV_CONF/nnmet/dupip/myShopDomain
2. Within each new directory, myShopDomain in this example, you need
to create a dupip.conf file and add commands to this file that define
the OAD. You would create the following file for this OAD:
• Windows: %OV_CONF%\nnmet\dupip\myShopDomain\dupip.conf
• UNIX:$OV_CONF/nnmet/dupip/myShopDomain/dupip.conf
Refer to the following file for some examples and instructions on how
to add information to the dupip.conf file:
• Windows:%OV_CONF%\nnmet\dupip\dupip.conf
• UNIX: $OV_CONF/nnmet/dupip/dupip.conf
3. In the same directory as dupip.conf, create a file named
dupip.seed. This file lists the IP addresses (required) and node
names (optional) that you wish to manage for this OAD. Add the IP
addresses in the first column and the optional node names in the
second column. Enter one IP address and node name per line as
described in the dupip.conf file.
IMPORTANT Do not add the virtual IP address of an HSRP group to the

dupip.seed file.
NOTE Your name resolution scheme must be able to resolve each node
name in dupip.seed to the IP address given for it. In other words,
the node name and IP address pairs in this file must agree with your
name resolution scheme.
44 Chapter 3
The seed file defines the discovery zone for the OAD, which appears
in the Overlapping Address Domains tab of the Extended Topology
configuration interface.
In this example, you would create the following file containing your
private IP addresses:
• Windows: %OV_CONF%\nnmet\dupip\myShopDomain\dupip.seed
• UNIX:$OV_CONF/nnmet/dupip/myShopDomain/dupip.seed
4. After configuring your dupip.conf and dupip.seed files, you should
run the ovdupip command to make sure your file entries are
syntactically correct. If there are errors in the files, this tool will tell
you what is wrong, and where to look to remedy the problem. See the
ovdupip reference page in NNM’s online help (or the UNIX manpage)
for more information.
NOTE To make sure your file entries are syntactically correct, run the
ovdupip command each time you modify one of your existing
dupip.conf files or add new dupip.conf files.
5. Go to the Extended Topology Configuration web page. You can

get there from Home Base by selecting the Discovery Status tab,
then selecting [Extended Topology Configuration]. See
“Accessing Dynamic Views” on page 16 for more information about
accessing Home Base and the Dynamic Views.
6. Select the Overlapping Address Domains tab.
7. Select [Refresh Configuration and Activate Changes] to read,
test, and deploy any changes or additions you made. If Extended
Topology determines your changes are free of errors, it creates a zone
for every defined OAD. These changes or additions will affect the
next discovery cycle.
8. To immediately initiate a complete discovery of all zones, execute, as
Administrator or root, the etrestart.ovpl command. You can
also select [Initiate Full Discovery Now] from the Discovery
Behavior tab located in the Extended Topology Configuration
menu.
Chapter 3 45
9. If you add new devices to or delete devices from a single OAD (zone),
you can save time by initiating an Extended Topology discovery on
that single zone.To initiate a discovery cycle for a specific zone, use
the following procedure:
a. From Home Base, select the Discovery Status tab.

b. Select [Extended Topology Configuration].
c. Select the Overlapping Address Domains tab.
d. Select the option button to the left of the zone you want to
discover.
e. Select [Discover Zone].
Deleting a Single OAD Zone You can remove information about a

single OAD zone without having to rediscover all of the other zones. To
do this, use the following procedure:
1. Go to the Extended Topology Configuration web page. You can

get there from Home Base by selecting the Discovery Status tab,
then selecting [Extended Topology Configuration].
4. Select the Overlapping Address Domains tab.
5. Select the option button to the left of the OAD zone you want to
delete.
6. Select [Delete OAD].
Understanding OAD Discovery

Figure 3-2 shows a typical OAD network where the management station
(MS) connects to a small number of devices (devices A and R), and to a
NAT (Network Address Translation) device.
46 Chapter 3
Devices on the left side of the NAT device are in OAD 0. Devices on the
right side of the NAT are in a non-zero OAD Domain (OAD 7 in
Figure 3-2) and may correspond to a specific ISP customer. The OAD
configuration uses the term Gateway to identify the NAT device. In
addition, there can be more than one Gateway per OAD.
Figure 3-2 Typical OAD Environment

OAD 7
OAD 0 Not
Discovered
C
MS A R NAT N B F G H E
Gateway
Although the management station communicates to devices in OAD 0

using the non-translated private addresses, it communicates to devices
in the other OAD (OAD 7) using the translated private addresses. This is
possible because the NAT device translates a subset of the private
addresses to the corresponding public translated addresses.
You can add entries to the $OV_CONF/nnmet/dupip/domain/dupip.seed
configuration file, specifying one address per device to be used as the
translated public management address for the device. Although other
addresses may be translated by the NAT, Extended Topology will use
this public management address for SNMP management and discovery.
NOTE The previous example used the directory name of domain in the path.
This directory name is normally provided by the network management
administrator and can be any string that is a valid directory name.
When deciding which address on a specific device to have Extended

Topology translate and use as the management address, it is good
practice to select the most upstream address, or to use the device’s
loopback address. Whenever possible, select an address that is available
Chapter 3 47
on an interface closest to the management station. This will facilitate

better analysis because partial failures on the device will still allow the
management station to talk to the device.
OAD and Undiscovered NAT Devices Although Extended Topology

uses the functionality of the NAT device for discovery and monitoring, it
may not actually discover the NAT device. For example, organizations
frequently deploy NAT devices for security or to isolate different parts of
the network. If these NAT devices do not respond to MIB-2 SNMP
queries, Extended Topology does not discover them. As a result, the NAT
device may not be in the extended topology or may not be connected
properly. When a NAT device is not discovered, the connectivity from the
extended topology may look more like the diagram in Figure 3-3.
Figure 3-3 Undiscovered NAT Device

OAD 7
OAD 0 Not
Discovered
C
MS A R N B F G H E
Gateway
Potential APA Concerns About Undiscovered NAT Devices If a

failure occurs in the OAD environment, shown in Figure 3-3, APA sets
status and emits alarms consistent with user expectations unless the
entire OAD environment becomes inaccessible.
For example, suppose that device N fails. When that happens, APA
considers all of the devices in the OAD 7 area to be in the Far-From-Fault
Area as shown in Figure 3-4. In this example, APA does not generate any
alarms, and sets the status of devices in OAD 7 to unknown. This
problem occurs because the fault area must contain at least one device
48 Chapter 3
that is accessible via SNMP or ICMP. Since device N is not connected to

any accessible upstream device, APA places device N in the
Far-From-Fault Area instead of the Fault Area.
Figure 3-4 OAD Scenario: Device N Fails
Normal Area Not Far-From_Fault Area (APA emits no alarms)

Discovered
OAD 0 C OAD 7
MS A R NAT
NAT N B F G H E
Normal Minor Not Discovered

Gateway
Critical Unknown
A similar result occurs if the NAT device fails or the downstream

interface of device R fails, as shown in Figure 3-5 on page 49. In either
case, the entire OAD 7 area will be inaccessible. APA will not emit any
alarms for OAD 7 because the entire area is Far-From-Fault. However,
the downstream interface of device R will be in the Fault area. Therefore,
APA sets the node status of device R to minor, sets the interface status to
critical, and emits an OV_APA_IF_DOWN R alarm. See“How APA Looks at
Failures” on page 94for more information.
Figure 3-5 OAD Scenario: NAT Device or Device R Interface Fails

OAD 0 Far-From_Fault Area (APA emits no alarms)
Fault Not OAD 7
Area Discovered
C
MS A R NAT
NAT N B F G H E
Interface 1 D
Down
Normal Minor Not Discovered
Gateway
Critical Unknown
Chapter 3 49
Resolving APA Concerns About Undiscovered NAT Devices You

can do some additional configuration to help APA accurately determine
the root cause in OAD environments with undiscovered NAT devices. To
do this, you need to configure Extended Topology to recognize a device
located downstream from a NAT device.
The $OV_CONF/nnmet/dupip/domain/dupip.conf configuration file
provides a mechanism, the NextHop keyword, to specify the device one
hop downstream from a NAT device. In the example shown in Figure 3-6
on page 51, the downstream device would be device N. If device N has an
IP Address of 10.1.2.3 and a public management address (NAT address)
of 15.1.2.3, then the following entry in the dupip.conf file would specify
this device: NextHop IP=15.1.2.3. This downstream device is
sometimes referred to the egress device (router or switch).
When entering an IP address using the NextHop keyword, you must
enter the device’s public address. You cannot enter an address range or
wildcard. If the NAT device maps several addresses associated with the
egress router, and Extended Topology discovers these addresses, this
results in several public addresses being associated with the egress
router. However, there is still only one associated management address.
In this situation, you must use the management address as the NextHop
address that you add to the dupip.conf file.
NOTE When deciding which address on a specific device to have Extended

Topology translate and use as the management address, it is good
practice to select the most upstream address, or to use the device’s
loopback address.
50 Chapter 3
You can find more information about using the NextHop keyword in the
$OV_CONF/nnmet/dupip/dupip.conf file.
Figure 3-6 OAD Scenario: Egress Device N Fails

OAD 0 Far-From_Fault Area (APA emits no alarms)
Not OAD 7
Normal Area Discovered Fault
Area C
egress D
device Minor
Normal Unknown
Gateway
Critical Not Discovered
When you specify one or more egress devices in the dupip.conf file
using the NextHop keyword, APA will process the egress routers
differently when they fail. For example, if an egress device fails, as
shown in Figure 3-6, APA will do no further analysis on the specified
egress device. Instead, APA will immediately report the egress device as
a primary failure in the Fault Area, report the egress device status as
critical, and generate the appropriate status alarms.
The result is that for a catastrophic failure where an entire OAD area is
inaccessible, only one alarm is generated that indicates the device that
failed or a device nearby. Thus, the network operator and administrator
will see not see an alarm browser that is cluttered with alarms from
downstream devices that are not actually critical. They do see an alarm
and a graphical indicator that a significant network failure has occurred.
Suppose an interface fails on device R, as shown in Figure 3-7 on
page 52. When this occurs, APA emits the following two alarms:
• Interface Down R IfIndex 1

• Node Down N
Chapter 3 51
APA sets both interface 1 and device N to a critical status, and sets
device R to a minor status.
Figure 3-7 Interface 1 on Device R Fails

Normal Area Fault Not Fault Far-From_Fault Area (APA emits no alarms)
Area Discovered Area
OAD 7
OAD 0
C
Interface 1 D
Down Minor
Normal
Unknown
Gateway Critical Not Discovered
In the next example, the NAT or Gateway device is handled like the
egress device, as both the NextHop and Gateway devices are identified in
the dupip.conf file. This is shown in Figure 3-8.
Figure 3-8 APA Behavior with NextHop and Gateway Devices Configured
Far-From_Fault Area (APA emits no alarms)
Normal Area Fault Not
Area Discovered OAD 7
Fault C
OAD 0 Area
Interface 1 D
Down Minor
Normal Unknown
Gateway Critical Not Discovered
In this configuration, suppose interface 1 on device R fails, causing an

entire OAD area to be inaccessible. This down interface normally
connects to the NAT device in OAD 0 (device R, interface 1). In this
example, APA generates the following three alarms:
• Interface Down R IfIndex 1

• Node Down NAT
• Node Down N
52 Chapter 3
APA analyzes NextHop and Gateway device failures more quickly than
other devices, and polls devices located in fault areas more quickly than
devices located in Far-From-Fault areas.
Understanding OAD View Status Information

The Active Problem Analyzer polls OAD addresses and reports device
status information in the OAD view. See “Using the Active Problem
Analyzer” on page 85 for more information.
You can identify OAD alarms in the Alarm Browser, as the alarms source
contains an @ symbol followed by the name of the Overlapping Address
Domain. See the trapd.conf reference page in NNM’s online help (or
the UNIX manpage) for more information.
Data Collections & Thresholds

You can enable Extended Topology to collect SNMP data for nodes
configured in an OAD. This allows you to do the following:
• Collect MIB data from network nodes automatically at regularly

scheduled intervals.
• Store the collected MIB data in a file.
• Set threshold monitoring on critical devices.
To enable Extended Topology to support SNMP data collection, use the
following procedure:
1. Edit the following file:
• Windows: %OV_LRF%\snmpCollect.lrf
• UNIX:$OV_LRF/snmpCollect.lrf
2. Add a -z option between the two colons as shown by the bold text in
the example below:
OVs_YES_START:pmd,ovwdb,ovtopmd:-z:OVs_WELL_BEHAVED:20:PAUSE
3. As Administrator or root, run the following command:
• Windows: ovaddobj%OV_LRF%\snmpCollect.lrf
• UNIX: ovaddobj $OV_LRF/snmpCollect.lrf
Chapter 3 53
4. As Administrator or root, run ovstop -c snmpCollect.

5. As Administrator or root, run ovstart -c snmpCollect.
NOTE You cannot configure performance, availability, exception, or inventory

reports for nodes configured in an OAD.
See Managing your Network with Network Node Manager for more
information about Data Collection and Thresholds.
54 Chapter 3
4 Problem Diagnosis
Chapter 4 55
Problem Diagnosis
Introducing Problem Diagnosis Functionality

Problem Diagnosis is an automated IP network path analysis tool that
presents end-to-end path information accurately. Furthermore, Problem
Diagnosis lets you see detailed information from nodes and devices in a
particular path.
Problem Diagnosis gives NOC and IP Network Operators & Engineers
tools for fast problem diagnosis and resolution in IP-based networks. In
particular, Problem Diagnosis offers a probe-based path tool that finds
and monitors the paths between itself and any reachable node that it is
configured to test. A Problem Diagnosis probe collects data over time,
and generates statistical and usage data about the paths it monitors.
Major Components
Problem Diagnosis has three primary components:
• The Web-based Graphical User Interface

You launch the Problem Diagnosis view from Home Base, which is a
Java applet that interacts with the Network Node Manager server to
present network information. Like all applets, it needs no
installation because it runs in the context of a Web browser.
The Problem Diagnosis view is simple to use and presents data in
easy-to-understand ways. From the Problem Diagnosis view,
Problem Diagnosis opens its own windows for you to work in.
• The Problem Diagnosis Server
The Problem Diagnosis server is the heart of the system, the
intelligence behind the Problem Diagnosis functionality. It
assimilates information and responds to requests from a user
running a Problem Diagnosis view.
The Problem Diagnosis server gets its topology data from NNM, from
Problem Diagnosis probes, and other HP OpenView applications.
Based on the topology data it mines from these sources, it can
present several alternative ways to examine the path(s) between
nodes.
• The Problem Diagnosis Probes
56 Chapter 4
Problem Diagnosis
The Problem Diagnosis probes are key suppliers of data to the

Problem Diagnosis system. Probes are independent Java
applications that can reside on any system of your choosing (see the
Release Notes for supported platforms and versions). There is no
limit to the number of probes you can install, or the number of paths
a probe can monitor. Likewise, a probe can be used by more than one
Problem Diagnosis server.
A probe collects information about paths between itself and any
desired target. It uses a technique similar to the familiar
traceroute utility, and runs periodically to test the route to the
target(s) it is configured for. On each run, it collects data about the
route:
— Devices along the route

— Lag time between devices
— New routes to the target
When you request probe data, the Problem Diagnosis server contacts
the probe for current data, so that you see the freshest information.
About Problem Diagnosis

With Problem Diagnosis, you see path maps and tables based on topology
data supplied by Problem Diagnosis probes. Probes can reside on any
system in the network, and can be configured to collect path information
to any reachable destination in the network.
Table 4-1 on page 58 provides a list of features of Problem Diagnosis as
well as limitations.
Chapter 4 57
Problem Diagnosis
Table 4-1 Summary of Problem Diagnosis Features
Can Cannot
• Show a path from where the • Show a path from any two
probe resides to any arbitrary endpoints.
reachable destination
• Show outbound interfaces
(firewalls can make some
(from ping's perspective)
hosts unreachable).
except on the probe's host.
• Show path utilization
statistics.
• Show current ping rates.
• Show baseline of ping rates.
• Send events to subscribers
(such as HP OpenView
Operations) if a path
becomes unreachable, path
changes, and so on.
• Show status of hops using
ping.
• Send brownout events to the
event browser indicating a
performance problem.
• Show IP-layer 2 devices
(switches, hubs, bridges,
and so on).
NOTE: After Problem Diagnosis
has determined path data, the
destination does not have to be
currently up (or reachable) to
see the historical paths.
See the online help for more details about retrieving information
collected by Problem Diagnosis.
58 Chapter 4
Problem Diagnosis
Starting a Problem Diagnosis View

After installed and configured, Problem Diagnosis is very simple to
operate. Follow these steps:
1. Start the Problem Diagnosis server with which you will connect, if it
is not already running. See “Starting and Stopping the Server” on
page 73 for instructions.
2. Start all probes for that server, if they are not already running. It
may take a few minutes before Problem Diagnosis has access to all
probes. See“Starting and Stopping a Probe” on page 73 for
instructions.
3. Access Home Base as follows:
a. Open a Netscape or Internet Explorer browser window. See the

Release Notes for supported browser versions.
b. Enter the following URL: http://hostname:7510
NOTE Replace hostname with the actual hostname or IP address of the

system on which NNM is installed. For example:
http://robot.cnd.hp.com:7510
4. From Home Base, select Problem Diagnosis View from the View
drop down list and click [Launch View]. The Problem Diagnosis main
dialog opens as shown in Figure 4-1.
Figure 4-1 Problem Diagnosis View
Chapter 4 59
Problem Diagnosis
Installing Remote Probes

After the installation of Network Node Manager and setup of Extended
Topology, a Problem Diagnosis probe and server is installed on the same
NNM management station. The probe is assigned to serve that Problem
Diagnosis server.
Additional Problem Diagnosis probes can be installed throughout your
network on HP-UX, Solaris, or Windows operating systems of your
choosing. Each installation of a Problem Diagnosis probe is assigned to
serve one Problem Diagnosis server. For more details, see “Linking
Servers and Probes” on page 65.
A probe can be used by multiple Problem Diagnosis servers. Conversely,
a Problem Diagnosis server can use multiple probes. After installing a
remote probe, determine if one of these deployment options is
appropriate for your situation. See “Linking Servers and Probes” on
page 65.
Consider installing probes in key locations in the network where they
can monitor crucial paths.
An automated installation package in the NNM distribution guides you
through the installation process of remote probes on HP-UX, Solaris, or
Windows operating systems of your choosing.
60 Chapter 4
Problem Diagnosis
Table 4-2 on page 61 outlines the procedures necessary to install a

Problem Diagnosis probe.
Table 4-2 Instructions for Installing Remote Probes
Platform of Probe Instructions

System
HP-UX 1. From the Problem Diagnosis server system, enter the

following from a command window prompt:
UNIX: cd $OV_MAIN_PATH/pdAE/bin
Windows: %OV_MAIN_PATH%\pdAE\bin
2. FTP probeHP.tar to the system where the remote probe is to
be installed. In particular, FTP the tar file to the root
directory of the target probe system.
3. From the remote probe system, as user root, untar
probeHP.tar in the root directory:
tar -xvf probeHP.tar
4. Enter: cd /opt/OV/bin/pdAE/bin
5. As user root, enter: ./pdpinstall.sh
This installs the probe software in /opt/OV/bin/pdAE.
You are prompted for the name of the Problem Diagnosis
server with which the probe will communicate. Enter the
fully-qualified DNS name of the assigned server. For
example, to assign the probe to the Problem Diagnosis server,
Minotaur, enter Minotaur.cnd.hp.com when prompted.
Chapter 4 61
Problem Diagnosis
Table 4-2 Instructions for Installing Remote Probes (Continued)

System
Solaris 1. From the Problem Diagnosis server system, enter the

2. FTP probeSUN.tar to the system where the remote probe is
to be installed. In particular, FTP the tar file to the root
directory of the target probe system.
3. From the remote probe system, as user root, untar
probeHP.tar in the root directory:
tar -xvf probeHP.tar
4. Enter: cd /opt/OV/bin/pdAE/bin
5. As user root, enter: ./pdpinstall.sh
This installs the probe software in /opt/OV/bin/pdAE.
62 Chapter 4
Problem Diagnosis
Table 4-2 Instructions for Installing Remote Probes (Continued)

System
Windows 1. From the Problem Diagnosis server system, enter the

2. FTP probeWIN.zip to the system where the remote probe is
to be installed.
3. From the remote probe system, unzip probeWIN.zip in the
root (C:\ by default) directory. This unpackages the zip file
to C:\Program Files\HP OpenView.
4. Go to C:\Program Files\HP OpenView\pdAE\bin
5. Double-click pdpinstall.vbs. This installs the probe
software in C:\Program Files\HP OpenView\pdAE.
The Problem Diagnosis probe starts immediately, and is configured to

run automatically at system startup.
Chapter 4 63
Problem Diagnosis
Configuring Problem Diagnosis

A configuration XML file, pdconfig.xml, is created on the Problem
Diagnosis server when Problem Diagnosis is installed. On the system
where Problem Diagnosis is installed, the configuration file can be found
at:
UNIX: $OV_MAIN_PATH/pdAE/config/pdconfig.xml
Windows: %OV_MAIN_PATH%\pdAE\config\pdconfig.xml
You can use the configuration XML file to tweak your Problem Diagnosis
configuration. In particular, use the configuration XML file to:
• Add probes to the list of probes that the Problem Diagnosis server
knows of. See “Linking the Server to a Probe” on page 65.
• Notify servers of a probe’s existence. See “Linking the Probe to a
Server” on page 67.
• Tune brownout parameters. See “Configuring Brownouts” on
page 69.
• Change the server and probe ports used by Problem Diagnosis. See
“Configuring Server and Probe Ports” on page 70.
You can edit this XML file even if you have no experience with XML, but
it requires accuracy; mistakes in the configuration XML file can cause
the Problem Diagnosis server or probe to not work correctly.
If non-ASCII characters are added to XML files, you must preserve the
UTF-8 codeset for these characters.
NOTE The Windows Notepad editor allows files to be saved in the UTF-8 code
set. On many UNIX platforms, the iconv command can be used to
translate from Shift JIS (or any other code set) into UTF-8 to make
editing in a non-UTF-8 codeset simpler.
HP strongly recommends that you make a backup copy of the XML file
before editing, so that you can easily recover if necessary.
64 Chapter 4
Problem Diagnosis
Linking Servers and Probes

As you install a Problem Diagnosis probe, you assign it to a Problem
Diagnosis server. The two transparently establish the configuration
necessary to communicate, and the probe automatically shows up in the
probe list on the server.
However, a Problem Diagnosis server can get path data from any probe,
providing the server is configured to know about the probe.
There are two ways to establish communications between a server and a
probe that was not initially assigned to that server.
• You can add the probe to the list of probes the server knows of. This
method is most useful when you want a server to know about several
probes that it could draw data from; that is, when you have one
server that will use many probes. This approach is covered in
“Linking the Server to a Probe” on page 65.
• You can configure the probe to notify the server of its existence, and
let the server reconfigure itself. This method is most useful when you
want a probe to know about several servers that it provides data to;
that is, when you have one probe to be used by many servers. This
approach is covered in “Linking the Probe to a Server” on page 67.
Linking the Server to a Probe

There are two steps to configure the server to contact a probe which was
assigned to a different server when it was installed:
1. Manually edit the Problem Diagnosis configuration XML file on the

Problem Diagnosis server to define which probe(s) the server can use.
This file is located at the following location:
If you cannot find the configuration XML file on your system, it is
created when a probe is installed and assigned to the server. Until
that happens, there is no Problem Diagnosis configuration XML file.
The configuration XML file initially contains:
<?xml version= "1.0" encoding=”UTF-8” ?>
<PD_CONFIG>
<PROBELIST>
Chapter 4 65
Problem Diagnosis
<PROBE>
<HOST_NAME> Icarus.naucrates.com </HOST_NAME>
<IP_ADDRESS> 15.2.116.83</IP_ADDRESS>
</PROBE>
</PROBELIST>
</PD_CONFIG>
The four lines in bold text create a "Probe Definition", which
identifies Icarus as hosting a probe that the server can use. You can
use more probes by adding additional Probe Definitions. Probe
Definitions must fall between the <PROBELIST> and </PROBELIST>
tags, and they cannot overlap.
In the example file above, you can add access to another probe
(Daedalus) by inserting the following lines in the configuration XML
file on the server:
<PROBE>
<HOST_NAME> Daedalus.naucrates.com </HOST_NAME>
</PROBE>
The resulting file looks like this:
<?xml version= "1.0" encoding=”UTF-8” ?>
<PD_CONFIG>
<PROBELIST>
<PROBE>
<HOST_NAME> Icarus.naucrates.com </HOST_NAME>
</PROBE>
<PROBE>
<HOST_NAME> Daedalus.naucrates.com </HOST_NAME>
<IP_ADDERSS> 15.2.116.72</IP_ADDRESS>
</PROBE>
</PROBELIST>
</PD_CONFIG>
66 Chapter 4
Problem Diagnosis
2. After saving the pdconfig.xml file, stop and restart the server to
activate the changes (see “Starting and Stopping the Server” on
page 73). Allow several minutes for the probe and server to
synchronize.
When you access the server, you can now choose to use either Icarus
or Daedalus as the probe.
Linking the Probe to a Server

There are two steps to make a probe (which was assigned to one server
when it was installed) notify another server of its existence:
1. Manually edit the probe configuration file (on the probe system),
which names the server it should notify when it initializes. The probe
configuration file is located as follows:
UNIX: $OV_MAIN_PATH/pdAE/config/npprobe.conf
Windows: %OV_MAIN_PATH%\pdAE\config\npprobe.conf
The probe configuration file looks like this:
SERVER=Minotaur.naucrates.com
SERVER_IP=12.12.121.212
SERVER_PORT=8068
The two lines in bold text identify the Problem Diagnosis server,
which was the server specified when the probe was installed. When
the probe initializes, it notifies the server specified here of its
existence. If necessary, the server adds the probe to its list of known
probes.
You can have the probe notify additional servers of its presence.
Change the bold lines in the probe configuration file to identify
another server. In the example file above, we can notify another
Problem Diagnosis server that the probe exists by changing the bold
lines in the probe configuration file to give the hostname and IP
address of the new server, as follows:
SERVER=Aeolus.naucrates.com
SERVER_IP=12.12.112.121
Chapter 4 67
Problem Diagnosis
IMPORTANT If you modify the existing lines, do not add any additional lines! The
resulting file looks like this (on a Windows host):
SERVER=Aeolus.naucrates.com
SERVER_IP=12.12.112.121
SERVER_PORT=8068
IMPORTANT A probe can only communicate with servers that use the port defined
by that probe (8068 in this example). If you change the port used by a
server, you have to reconfigure each probe that the server uses (via
the SERVER_PORT definition in npprobe.conf) to use the new port.
See the “Configuring the Server Port” on page 71 for instructions on
changing the server port.
NOTE It is not a good idea to have more than one Problem Diagnosis server
configured. Since there is no way for one Problem Diagnosis server to
talk to another Problem Diagnosis server, it could be difficult to
obtain the path information you request.
2. After saving the changes, stop and restart the probe (see “Starting
and Stopping a Probe” on page 73). This causes the probe to
synchronize with its server. Because Aeolus has no previous
knowledge of the probe, it adds the probe to its pdconfig.xml file.
After the probe is added to the list of known probes on a server (like
Aeolus), it remains on that list even if you repeat this process to add
it to yet another server.
Allow a few minutes for the probe and server to synchronize.
At this point, both of the servers (Aeolus and Minotaur) can use the
probe to show path data.
68 Chapter 4
Problem Diagnosis
Configuring Brownouts
When Problem Diagnosis performs a trace from a probe to a destination,
the packet round trip time to the destination is noted. If the packet time
exceeds a calculated limit (or threshold), then Problem Diagnosis pings
the destination once every minute for fifteen minutes, by default. Each
packet round trip time is noted and compared to its threshold. By
default, when a eight or more of the fifteen times exceed the threshold,
then a brownout event is generated.
Problem Diagnosis determines the point where a brownout might be
occurring by looking at the nodes (or hops) along a path from the probe to
the destination. When a hop time exceeds its calculated limit, then
Problem Diagnosis assumes that a spike is occurring between that hop
and the previous hop.
A brownout event is sent to the alarm browser containing the probe, the
destination, and the two hops where the spike appears to be occurring.
To change the way brownout events are generated, you can modify the
Problem Diagnosis configuration file, pdconfig.xml, located at:
The Problem Diagnosis configuration file enables you to tune the
brownout parameters described in Table 4-3 on page 69.
Table 4-3 Brownout Parameters in Problem Diagnosis Configuration File
Tunable Parameter Description Default Value
BROWNOUT_INTERV Time in milliseconds that Problem 86400000

AL Diagnosis waits before generating
another brownout event for a probe and
destination combination.
Chapter 4 69
Problem Diagnosis
Table 4-3 Brownout Parameters in Problem Diagnosis Configuration File
Tunable Parameter Description Default Value
BUCKET_SIZE The number of measurements Problem 24

Diagnosis stores for a particular hop
from a particular path to the
destination. After the value is reached,
the oldest measurement is replaced by
the newest measurement.
NOTE: This parameter is not
recommended to be changed, especially
after data has been collected.
BROWNOUT_NUM_SA Number of times that Problem 15
MPLES Diagnosis will attempt to ping the
destination device. The frequency that
Problem Diagnosis attempts to ping the
destination device is once per minute.
BROWNOUT_NUM_ A number used to calculate the 3

DEVIATIONS threshold for brownout events. The
formula for determining the threshold is
the BROWNOUT_NUM_ DEVIATIONS times
the square root of the mean, plus the
mean.
BROWNOUT_BAD_SA The number of times that the ping round 8

MPLES trip time must exceed a threshold before
a brownout event is generated.
Configuring Server and Probe Ports

Ports 8068 and 8067 are used by the Problem Diagnosis server to
communicate internally (8068), and with probes (8067). If either of these
ports has been taken by other software, the port(s) used by the server
must be changed. In the case of port 8068, probes must be reconfigured to
reflect changes to the server.
70 Chapter 4
Problem Diagnosis
Configuring the Server Port
NOTE Any probe accessed by a server that does not use port 8068 must be
reconfigured to accommodate this, and its data will not be available to
any server that uses another (such as the default) port.
To change the Problem Diagnosis server port number from 8068 to

another port use the following procedure:
1. Stop the Problem Diagnosis server and stop all probes assigned to
that server. See “Starting and Stopping the Server” on page 73 and
“Starting and Stopping a Probe” on page 73.
2. Edit the configuration XML file, pdconfig.xml, looking for the entry
<HTTP_PORT>8068</HTTP_PORT>. Replace 8068 with a port
number that is not used by any other networking software.
3. For all relevant Problem Diagnosis probes, edit
<Install_directory>/config/npprobe.conf and replace 8068
with the same port number you used in the previous step.
4. Restart the server and restart all reconfigured probes.
Configuring the Probe Port

To change the Problem Diagnosis probe port number from 8067 to
another port use the following procedure:
1. Stop the Problem Diagnosis server. See “Starting and Stopping the
Server” on page 73.
2. Edit the configuration XML file, pdconfig.xml. For each <PROBE>
entry, edit the entry <HTTP_PORT>8067<HTTP_PORT>. Replace 8067
with a port number that is not used by any other networking
software.
3. Oneach probe system, edit:
UNIX: /etc/services
Windows: %windir%\system32\drivers\etc\SERVICES
Replace the value of the netpath_http entry with the new port
number.
4. Restart the server.
Chapter 4 71
Problem Diagnosis
Configuring Probes
Problem Diagnosis includes a web-based probe configuration utility. To
configure a probe, first start the probe configuration utility as follows:
1. Start the probe to be configured, and also a Problem Diagnosis server

that uses this probe. These components must both be running before
you can proceed. See “Starting and Stopping the Server” on page 73
and “Starting and Stopping a Probe” on page 73.
2. Launch Home Base. You can access Home Base from your browser
using the following URL: http://hostname:7510. See “Starting a
Problem Diagnosis View” on page 59 for details.
3. From Home Base, select Problem Diagnosis View from the View
drop down list and click [Launch View]. The Problem Diagnosis
main dialog opens.
4. Click [Configure] to open the Problem Diagnosis Configuration
window.
From the Problem Diagnosis Configuration window, set probe targets
and collection parameters by doing the following:
1. In the "Select Probe" list, choose the location of the probe you want to
configure. If the list is empty, no probes have been installed.
2. Use the [Add] button to create an entry in the targets list.
Double-click in the Target field and edit it to contain the
fully-qualified name of a destination node. Problem Diagnosis will
trace the paths to this node. Edit other fields in the entry as
necessary; see the Problem Diagnosis Probe Configuration topic in
the Online Help for more details.
3. After adding all desired targets, click [Apply] or [OK]. Both buttons
record your changes; [OK] closes the window, [Apply] keeps it open.
See the Problem Diagnosis Probe Configuration topic in the Online Help
for more details on configuring probes.
72 Chapter 4
Problem Diagnosis
Other Administrative Tasks

This section describes other administrative tasks that you may need to
perform periodically, such as stating and stopping Problem Diagnosis
servers and probes.
Starting and Stopping the Server

To start and stop the Problem Diagnosis server, execute the following
from a command window prompt:
• To start the Problem Diagnosis server, enter:

UNIX: $OV_BIN\ovstart pd
Windows: %OV_BIN%\ovstart pd
• To stop the Problem Diagnosis server, enter:
UNIX: $OV_BIN\ovstop pd
Windows: %OV_BIN%\ovstop pd
NOTE This automatically starts and stops the probe on the Problem Diagnosis
server. You do not need to start and stop the server probe separately.
NOTE Do not force the termination of the Java process (kill -9 on UNIX
operating systems or [End Process] from the Task Manager on
Windows operating systems); doing so my cause irrevocable corruption of
the Problem Diagnosis data.
Starting and Stopping a Probe

Problem Diagnosis probes start immediately after installation, and are
configured to run automatically at system startup.
The commands for starting and stopping a Problem Diagnosis probe
differ according to the platform on which the probe runs.
Chapter 4 73
Problem Diagnosis
Note that on Windows operating systems, probes are installed as a

Windows service.
Platform Instructions
UNIX To stop a probe, execute:
1. cd $OV_MAIN_PATH/pdAE/bin
2. ./pdcentral.sh -stopProbe
To start a probe, execute:
1. cd $OV_MAIN_PATH/pdAE/bin
2. ./pdcentral.sh -startProbe
Windows To stop a probe service, execute:
1. Right-click on the My Computer desktop icon

and select the Manage menu item.
2. In the navigator pane, double-click Services
and Applications.
3. Double-click Services.
4. In the details pane, select the NetPath
service, and click Stop in the applet toolbar.
To start a probe service, execute:
1. Right-click on the My Computer desktop icon

and select the Manage menu item.
2. In the navigator pane, double-click Services
and Applications.
3. Double-click Services.
4. In the details pane, select the NetPath
service, and click Start in the applet toolbar.
74 Chapter 4
Problem Diagnosis
Limitations and Oddities
Known Limitations
These are the limitations and special behaviors in Problem Diagnosis.
Categories include:
• General Notes
• Install Notes
• Problem Diagnosis Probe Notes
• CLASSPATH Conflict
• MOZILLA_HOME Setting
General Notes
• In some circumstances, the Problem Diagnosis server triggers a

stack trace (visible in the Java console and/or the server error log)
when the browser is exited. The exception is non-fatal, and is
ignored. The operation of the server is not affected.
• Sometimes a DNS name resolves to multiple hosts, as in the case of a
web farm. To improve performance, web farms and similar scenarios
distribute incoming requests to one of an array of hosts, always
choosing the least-busy host. For example, the DNS name of
www.yahoo.com does not refer to just one host. At this writing,
www.yahoo.com resolves to at least eight different IP addresses. The
final host (the one that is assigned to respond to your query)
responds with its IP address, and not the generic DNS name.
To resolve this issue for web farms, configure a probe with a
destination for each for each web server using each web server’s IP
address, rather than a defining a single destination using the DNS
address.
• X-Windowing: Severe display problems (including a complete failure
to display the applet) have been observed when using X-windowing
programs to redirect the Java applet display from UNIX® systems to
Windows systems.
Chapter 4 75
Problem Diagnosis
• Windows systems only: If HP OpenView VPIS is also installed on the

same system as NNM, you may have problems with the Problem
Diagnosis/NNM integration. A symptom of this conflict is an error
message similar to this (depending on your JRE):
The procedure entry point ??1List@@UAE@XZ be located in the
dynamic link library ovutil.dll
To solve this problem follow these steps:
Windows Right-click on the My Computer desktop icon, and choose

the Properties menu item. Click on the Advanced tab.
Click the Environment Variables button. Find the System
Variable named Path, and edit its Value so that the NNM
bin directory (for example, C:\Program Files\HP
OpenView\nnm\bin) comes before the VPIS bin directory
(for example, C:\rpmtools\bin). Click Apply, then Close.
Install Notes
• The installer cannot use the JRE from Symantec. You must have a
different JRE in the PATH ahead of the Symantec JRE.
Problem Diagnosis Probe Notes
• When you first install a probe, the associated server should be

running. If it is not, and if it is not started within an hour of the
probe's installation, then it may take up to an hour after the server is
started for it to establish communications with the probe. You can
eliminate this lag by stopping and restarting the probe after starting
the server.
• A default gateway must be permanently configured for any system
that hosts a probe. If the default gateway is not set, you will see
routing loop error messages when no such loop necessarily exists.
• Path requests where the probe and target endpoints are the same
device (for example, from rantrave.diatribe.com to
rantrave.diatribe.com) have unpredictable results.
• Windows only: On some systems, running the probe as a service can
cause the screen saver to stop working. This can be a security hazard
if the computer will not lock when unattended. If this happens, you
may want to run the probe in standalone mode rather than a service.
76 Chapter 4
Problem Diagnosis
To remove the probe from the Windows service, use the following
commands from a command window prompt:
1. Enter: cd %OV_MAIN_PATH%\pdAE\bin
2. Enter: pdcentral.bat -uninstall
To run the probe in standalone mode, issue the following commands
from a command window prompt:
1. Enter: cd %OV_MAIN_PATH%\pdAE\bin
2. Enter: pdcentral.bat -startProbeNoSvc
CLASSPATH Conflict
• In some situations, your system's Java CLASSPATH environment

variable can cause problems starting or running any Java-based
interface in Problem Diagnosis. Typical symptoms of this are:
— The Problem Diagnosis application window fails to launch, and

the browser status line reads "Applet not inited".
— Netscape gives errors when you try to raise the "Online Help",
and the navigation panel in the help window is blank.
If you see these symptoms (or other unexplained failures in the Java
interfaces), you should run Problem Diagnosis under a shell with an
empty CLASSPATH, as follows:
UNIX • Open a new terminal window.

• Type: export CLASSPATH=""
• Type: netscape &
• Start Problem Diagnosis from the
resulting browser as usual. See
“Starting a Problem Diagnosis View” on
page 59.
Chapter 4 77
Problem Diagnosis
Windows • Open a command window

(Start:Programs->Command Prompt).
• Type the following command: set
CLASSPATH=""
• Start Problem Diagnosis by launching
your browser from this command
window! See “Starting a Problem
Diagnosis View” on page 59.
Under default installations, the
commands to launch Netscape and
Internet Explorer are:
— Netscape: "C:\Program
Files\Netscape\Communicator\P
rogram\netscape.exe"
— Internet Explorer: "C:\Program
Files\Plus!\Microsoft
Internet\iexplore.exe"
See also MOZILLA_HOME Setting for a similar issue.
MOZILLA_HOME Setting
• On UNIX systems there are conditions under which the Problem

Diagnosis applets and/or Online Help will not launch correctly in
Netscape. If you have trouble of this kind, follow these steps:
— Exit from Netscape.

— Enter: export
MOZILLA_HOME=<Netscape_Installation_Directory>
— Restart Netscape.
— Restart Problem Diagnosis.
See also CLASSPATH Conflict for a similar issue.
78 Chapter 4
Problem Diagnosis
Java Oddities
As you may already be aware, Java is still maturing as a technology.
During this process of maturation, there remain some minor instabilities
or, more generously put, “quirks” that you may want to be aware of.
Below are some examples. With the exception of the CLASSPATH conflict
issue, the workarounds are very simple.
• The following can occur on Windows operating systems whose

Display settings have the "Show window contents while dragging"
option turned on:
If you drag the Main Dialog window after pressing the [Go]
button—but before the path list appears—the resulting path list is
obscured. It is actually present, but you have to drag the bottom
border of the window down to see it. This only seems to occur if you
have turned on the "Show window contents while dragging" display
option in your Windows configuration. If this Java quirk is too
annoying, turn off this Windows option.
• The [Go] and [Stop] buttons in the Main Dialog window may
randomly change colors. This seems to occur most commonly when
another window overlays the left side of the Main Dialog window and
bisects the [Go] button vertically. This problem has only been seen
on Windows operating systems, and the culprit is actually the video
display driver. If you switch to another Display:Settings:Color
Palette value, the problem should disappear. In one case, using the
"16777216 Colors" setting caused the problem, but switching to the
"65536 Colors" setting solved it.
• After you press [GO], the button is disabled (grayed-out) until the
results of your request are available. Depending on the Java plug-in
and the platform you are using, you may or may not see a "Busy"
cursor (something like an hourglass or watch) during this period to
indicate that your request is being serviced. If the "Busy" cursor does
not appear, you should assume that Problem Diagnosis is working,
and will shortly return the results of your request.
• HP-UX only: Occasionally when you start the configuration applet,
the window does not start correctly. It displays only a title bar and
the "Applet Window" warning message. If this happens, just drag the
corner to enlarge the window; the content will be displayed correctly.
Chapter 4 79
Problem Diagnosis
• As noted under Known Limitations—and repeated here because it is

a Java quirk—in some situations, your system's Java CLASSPATH
environment variable can cause problems starting or running any
Java-based interface in Problem Diagnosis. Typical symptoms of this
are:
— The Problem Diagnosis application window fails to launch, and

the browser status line reads "Applet not inited".
— Netscape gives errors when you try to raise the "Online Help",
and the navigation panel in the help window is blank.
If you see these symptoms (or other unexplained failures in the Java
interfaces), you should run Problem Diagnosis under a shell with an
empty CLASSPATH, as follows:
UNIX • Open a new terminal window.

• Type: export CLASSPATH=""
• Type: netscape &
• Start Problem Diagnosis from the
resulting browser as usual. See
“Starting a Problem Diagnosis View”
on page 59.
80 Chapter 4
Problem Diagnosis
Windows • Open a command window

(Start->Programs->Command
Prompt).
• Type the following command: set
CLASSPATH=""
• Start Problem Diagnosis by launching
your browser from this command
window!
Under default installations, the
commands to launch Netscape and
Internet Explorer are (quotes
required):
— Netscape: "C:\Program
Files\Netscape\Communicator\P
rogram\netscape.exe"
— Internet Explorer: "C:\Program
Files\Plus!\Microsoft
Internet\iexplore.exe"
Chapter 4 81
Problem Diagnosis
Troubleshooting Problem Diagnosis

This section provides some tips and hints on troubleshooting Problem
Diagnosis.
Cleaning Up a Corrupt Database

The Problem Diagnosis database contains all of the path data collected
from the Problem Diagnosis server and all of the remote probes. The
Problem Diagnosis database directory resides on the NNM management
station in:
UNIX: $OV_MAIN_PATH/pdAE/database
Windows: %OV_MAIN_PATH%\pdAE\database
If your Problem Diagnosis database is in a corrupt state and cannot be
recovered, clean out the contents of the Problem Diagnosis database
directory:
1. Stop Problem Diagnosis on the NNM management station by

executing the ovstop command:
UNIX: $OV_BIN/ovstop pd
Windows: %OV_BIN%\ovstop pd
2. Go to the database directory:
UNIX: $OV_MAIN_PATH/pdAE/database
Windows: %OV_MAIN_PATH%\pdAE\database
3. Remove all the files from the database directory, including pd.data,
pd.properties, and pd.script.
NOTE Removing the database files from the Problem Diagnosis database
directory effectively deletes all of your stored data. This includes all of
the data collected by the Problem Diagnosis probes.
82 Chapter 4
Problem Diagnosis
Checking Status of Problem Diagnosis Server

Typically, you would check the status of an NNM component by
executing ovstatus. However, sometimes the output from executing
ovstatus pd indicates that the Problem Diagnosis server is up and
running when it is not.
The best way to check the status of the Problem Diagnosis server is to
check the connection to the Problem Diagnosis database. If a connection
to the database can be established, then the Problem Diagnosis server is
up and running.
To connect to the database and verify that the Problem Diagnosis server
is running, execute:
pdcentral.sh -dbmanager
Checking Status of Remote Probes

To determine whether a remote Problem Diagnosis probe is running,
check to see whether the Java process is running on the system hosting
the probe. If so, then the Problem Diagnosis probe is running:
ps -ef | grep java
For example, you should see a process listed similar to one provided here.
/opt/OV/jre/jre1.4/bin/PA_RISC/java com.hp.ov.pd.netpath.NPP
Chapter 4 83
Problem Diagnosis
84 Chapter 4
5 Using the Active Problem
Analyzer
Chapter 5 85
Using the Active Problem Analyzer
Understanding the Basics of the Active Problem Analyzer
Understanding the Basics of the Active

Problem Analyzer
The Active Problem Analyzer (APA) monitors device status, analyzes
problems on your network, and displays root cause information for
Extended Topology.
The NNM GUI (ovw) uses the netmon process to monitor device status,
among other things. Similarly, NNM Advanced Edition’s Extended
Topology functionality (Extended Topology) uses Active Problem
Analyzer (APA) to continuously monitor devices that you designate as
belonging to an Overlapping Address Domain (OAD) and report status
information. See Chapter 3, “Configuring Overlapping Address Domain
Discovery,” on page 41 for more information.
NOTE There are several documents that discuss NNM Advanced Edition’s
features. These documents refer to APA as either Active Problem
Analyzer or Advanced Problem Analyzer. Both phrases are valid
references to APA.
Extended Topology uses APA to continuously query Hot Standby Routing

Protocol (HSRP) routers and report HSRP group status information. You
must have a valid license for the Advanced Routing Smart Plug-in (SPI)
for NNM to use the HSRP functionality. See Chapter 8, “The Advanced
Routing Smart Plug-in,” on page 237 for more information. This
document assumes you have a valid license for the Advanced Routing
SPI.
APA analyzes the connectivity details from the extended topology to
provide you with accurate HSRP and OAD view status information. It
provides you with this information in the following ways:
• It analyzes information from neighboring interfaces in order to

provide better diagnostic information.
• It generates alarms indicating the root cause of an HSRP or OAD
problem. You will spend less time searching for the root cause of a
failure.
• It maintains node, interface, and address status attributes.
86 Chapter 5
• It modifies Dynamic View node status colors using node status and
other node attributes.
See “Understanding HSRP View Status Information” on page 260 for
more information about HSRP status information. See “Understanding
OAD View Status Information” on page 53 for more information about
OAD status information.
By default, APA monitors OAD status, and HSRP status if you have a
valid license for the Advanced Routing Smart Plug-in. If you want, APA
can largely replace the netmon process for monitoring your whole
network.
If you choose to have APA replace the netmon process for monitoring
your whole network, its default configuration allows it to poll devices as
shown in Table 5-1. There are a number of factors to consider before you
take that step. This chapter will help you understand APA, and to decide
what you want it to do.
Table 5-1 Default APA Polling Configuration
Device Type SNMP Polling ICMP Polling
Switch with No No Yes

Connected
Interfaces
Connected Interface Yes Yes

on Router
Connected Interface Yes No

on Switch
Connected Interface No Yes

on End Node
Unconnected Yes Yes

Interface on Router
with Interface
Administratively Up
Unconnected No No
Interface on Router
with Interface
Administratively
Down
Chapter 5 87
Table 5-1 Default APA Polling Configuration (Continued)
Device Type SNMP Polling ICMP Polling
Unconnected No No
Interface on Switch
with Interface
Administratively Up
Unconnected No No
Interface on Switch
with Interface
Administratively
Down
Board Yes N/A
APA also polls devices for configuration information and determines if its
interfaces may have renumbered. See “Configuration Polling and
Interface Renumbering” on page 105 for more information.
To find out how to enable APA, see See “Enabling and Disabling APA” on
page 109.
NOTE This paper contains references to both Extended Topology and extended
topology. Extended Topology refers to the overall functionality described
in the Using Extended Topology manual. In contrast, extended topology
refers to the information discovered by the Extended Topology
functionality and the database containing this information.
88 Chapter 5
Understanding How APA and the netmon Process Cooperate
Understanding How APA and the netmon

Process Cooperate
If you prefer, you can continue to use the netmon process as your network
monitor. Except for OAD and HSRP environments, which APA alone can
monitor, ovw has always used netmon for this purpose, and this is the
default setting.
However, you can make APA your primary network monitor. It offers
more accurate diagnostic information and faster throughput for greater
scalability.
NOTE Regardless of whether you have the netmon process or APA doing your
general IPv4 network monitoring, the netmon process is still essential for
device discovery.
To summarize, in addition to having APA monitor IPv4 addresses that

you designate as belonging to an OAD, you can make APA poll all of the
IPv4 interfaces listed in the hosts.nnm file (general IPv4 interfaces).
Once you complete your first Extended Topology discovery, you can view
these general IPv4 entries in the hosts.nnm file by looking in the
following location:
• Windows:%OV_DB%\nnmet\hosts.nnm
• UNIX: $OV_DB/nnmet/hosts.nnm
See Chapter 2, “Extended Topology Discovery,” on page 19 for more
information about Extended Topology discovery.
Before you switch over to APA monitoring, however, you should
understand the differences between the netmon process and APA. While
APA offers several significant advantages over the netmon process, some
users will find one or two specific characteristics of the netmon process
that make it indispensable to them.
You may have NNM installed as a management station in an NNM
distributed environment. Do not enable APA on NNM when it functions
as a management station with collection stations reporting information to
Chapter 5 89
it. You can enable APA on NNM if it only functions as a collection station
or as a standalone management station, having no collection stations
reporting information to it.
If you enable APA to poll your general IPv4 interfaces, it provides you
with more accurate diagnostic information. Here is a brief summary of
the advantages APA offers when diagnosing network failures:
• It analyzes information from neighboring interfaces and verifies that

the failure is real before generating the alarm.
• It identifies link failures based upon Extended Topology
connectivity.
• It suppresses transient failures due to spanning tree reconvergence.
• It polls devices using both SNMP and ICMP as it deems appropriate
for the situation.
• It improves polling performance by ignoring unconnected interfaces
and utilizing multi-threaded processes.
• It updates status information for objects in both ovw and Dynamic
Views.
If you have APA take over the general IPv4 interface polling, the netmon
process stops monitoring these interfaces. As APA makes status changes
to the extended topology, it sends updates about the statuses of
ovw-based interfaces to the ovtopmd process.
The ovtopmd process generates status events as it normally does. It
passes this status information to the ipmap process, and ultimately, the
ovw user interface. Dynamic Views get their information from the
extended topology if it is available for a node, returning to the ovtopmd
process for status if necessary.
90 Chapter 5
Table 5-2 compares APA with the netmon process. This should help
clarify some of the differences between the netmon process and APA.
Table 5-2 Comparing APA and the netmon Process
NNM Prior to Enabling APA NNM with APA Enabled
NNM’s polling list comes from APA takes its polling list
ovtopmd. exclusively from the extended
topology. You need to make sure
that your important nodes are not
blocked by the
bridge.noDiscover file.
APA does not generate status NNM generates APA alarms only.
alarms for devices in the general It does not generate NNM status
IP environment. NNM alarms alarms. See the trapd.conf
appear as they normally do. reference page (or the UNIX
manpage) for more information.
NNM events participate in APA events participate in event

event correlation and appear in correlation and appear in the
the Alarm Browser. Alarm Browser after verification.
Root cause analysis is based on Root cause analysis is based on

netmon process information APA’s more detailed information
available to ECS. Alarms are available to ECS. A single alarm is
sent for every device affected by sent only for the actual root cause,
a failure. not one for each affected device.
Events that communicate
topology changes to other NNM
processes may be logged and not
used by ECS.
NNM considers an address to be There are separate board,

an interface object. interface, and address objects.
Extended Topology and APA allow
for multiple boards per node,
multiple interfaces per board, and
multiple addresses per interface
with each interface having its own
status.This clarity of status allows
better propagation to node status.
Chapter 5 91
The netmon process derives APA uses both ICMP and SNMP to
device interface status using determine interface status,
ICMP (or SNMP if the device is depending on the APA
a switch). configuration.
You can add address
information to the
netmon.snmpStatus file to have
NNM use SNMP status polling
for specific interfaces. Doing this
turns off ICMP polling for the
targeted interfaces. See the
netmon reference page (or the
UNIX manpage) for more
information.
ovw shows propagated interface Some objects have their own basis
status. Status propagation is the for status. For example, HSRP
sole basis for node, segment, analyzes the various status values
and network status. to determine HSRP group status.
Internally, the ovtopmd process The ovet_poll process generates

generates status change events status alarms. It does not send
for each device affected by a secondary failure alarms. APA
failure. changes the status in the extended
topology and only the root cause
event is sent through the event
system.
The ipmap process listens to the Dynamic Views listen for and
various status change alarms display topology changes.The
and updates node, segment, and ovet_poll process sends
network status. Extended Topology node status to
ovw nodes, segments, and
networks.
92 Chapter 5
Dynamic Views get status from Dynamic Views get status from
the ovtopmd process for nodes the extended topology. If you
and interfaces. enable APA for IP, the ovtopmd
process gets its IP status from
APA.
How APA and the netmon Process Share Information

The following information provides some additional details on how APA
and the netmon process cooperate with each other:
• APA can behave in two different ways:
— It can monitor HSRP and OAD only, which is the default

behavior.
— You can enable APA to monitor everything that exists in the
extended topology. See “Enabling and Disabling APA” on
• If you enable APA, it forwards status information to both the
ovtopmd process and Extended Topology. However, APA only
forwards critical device status information to ovtopmd. As a result,
NNM only displays node, interface, or address status pointing to the
possible root cause of the failure. NNM will not display all of the
secondary status failures in ovw. NNM does not change the ovw
status for secondary nodes.
• Dynamic Views show extended topology status when available; they
show status that comes from the ovtopmd process when APA is not
monitoring a device or interface. Devices not being monitored by APA
are shown as having a Not Monitored status.
• A Neighbor View within an OAD shows APA status.
• If you view the Node Details or Interface Details pages of a
device, it will display information as follows:
— If APA is monitoring a node, the pages display extended topology

and APA status information.
Chapter 5 93
— If the netmon process is monitoring a node, the page displays

status from the ovtopmd process.
How APA Looks at Failures

APA diagnoses network failures by doing additional failure analysis.
During this failure analysis, APA does not generate many alarms for
nodes that are not immediately adjacent to the detected fault. It
attempts to generate one alarm showing the root cause of a failure.
If APA determines that a node is down, it generates an
OV_APA_NODE_DOWN alarm for the node and sets the status to
critical. This alarm name implies a primary failure.
Failures detected on the other side of a known fault are a result of that
fault, and APA calls them secondary failures. You can see these
secondary failures by drilling down from the corresponding primary
failure. This eliminates alarms from the Alarm Browser for devices that
are not known to have failed.
APA and Failure Analysis Details

During failure analysis, APA attempts to distinguish among the
following three areas of the network:
• Normal Area: The area of the network near the management station
where all the devices are operational and can be accessed via ICMP
or SNMP. This area could be large (multiple hops).
• Fault Area: This area includes devices that contain a fault or are
directly connected to a device downstream from the management
station that contains a fault. This area will always contain at least
one device that is up and responding to SNMP.
• Far-From-Fault Area: This area corresponds to devices that are
downstream from the fault. That is, if you traverse a path from the
management station to these devices, you will sequentially pass
through the Normal Area and the Fault Area, and finally arrive at
the devices in the Far-From-Fault Area.
APA handles each of the these areas differently:
94 Chapter 5
• Normal Area: Devices located in this area are up and responding.

Device statuses should be normal (or responding for addresses) in
the extended topology. You may see an OV_APA_xxx_UP alarm (where
xxx is NODE, IF, CONNECTION, ADDR,BOARD, or AGGPORT) if a device was
in the Fault Area and the fault has been fixed.
• Fault Area: APA analyzes this area, determines the most likely root
cause object (node, interface, connection, address, board, or
aggregated port), and generates a single alarm for this object.
NOTE Information presented in this section considers the term down to be

synonymous with the term critical. These terms can be used in
several ways:
— Either term may imply a status of critical in the extended

topology. APA may emit an OV_APA_xxx_DOWN alarm for critical
devices.
— Either term can refer to a device being unresponsive due to the
failure of another device between the management station and
the device.
The information provided in this section carefully sets the context so
that you can interpret the proper meaning of these terms.
For example, if APA determines that a node is down, it will emit an

OV_APA_NODE_DOWN alarm for the node. In this example, APA
considers objects contained by the node (interfaces, addresses, and
boards) to be secondary failures and displays them with an unknown
status in the extended topology. APA will emit an
OV_APA_IF_UNREACHABLE, OV_APA_ADDR_UNREACHABLE,
OV_APA_BOARD_UNREACHABLE, or OV_APA_CONNECTION_UNREACHABLE
alarm as appropriate.
An interface in the extended topology may contain one or more
addresses. If an interface status changes to down or unreachable, all
contained addresses (that are polled) will change status to
unreachable and an OV_APA_ADDR_UNREACHABLE alarm to be
emitted.
NOTE An alarm name that contains the term DOWN, as in

OV_APA_NODE_DOWN, implies a primary failure.
Chapter 5 95
An alarm name containing the term UNREACHABLE, as in

OV_APA_IF_UNREACHABLE, implies a secondary failure.
Objects that are experiencing a secondary failure are failing because
of a primary failure object. Alarms for secondary failures are not
directly visible in the alarm browser. They can only be seen by
drilling down from the corresponding primary failure.
• Far-From-Fault AreaThis area consists of devices that are not faulty

but are effected by the fault. APA does not emit an alarm for these
devices, but sets the status to unknown (or unreachable for
addresses) in the Dynamic Views. APA inhibits alarm generation in
this area, eliminating clutter from the alarm browser by excluding
alarms for devices that are not in the Fault Area. This greatly
improves the performance of the alarm system.
NOTE Although APA excludes alarms from the Alarm Browser for all
devices that are located in the Far-From-Fault area, you can change
this behavior. You can configure APA to emit the alarms for
important nodes that you designate. See “Configuring APA to
Display Alarms from Important Nodes” on page 118 for more
information.
To illustrate the performance improvement, suppose a fault occurs,

resulting in 1,000 inaccessible nodes. Suppose each of these nodes
contained four interfaces and five addresses. Although APA might
only generate ten alarms for the Fault Area, it could emit ten alarms
(one for the node, one for each interface, and one for each address) for
each of the inaccessible nodes (in this case, 1000 nodes). In this
example, without eliminating alarm generation, APA would have to
change the status of 10,000 objects in the Far-From-Fault Area. By
not generating the corresponding 10,000 alarms associated with the
Far-From-Fault Area, we avoid inefficiently using pmd process, ECS
correlation and Composer correlator resources.
Refer to Figure 5-1 on page 97 for the following example:
Suppose that node F fails, and the management station (MS) cannot
access nodes G, H, and E. Node F’s failure will cause all of Node F’s
interfaces to fail. This also causes the connected interfaces on nodes
96 Chapter 5
C and D to fail. The management station, node N, and node B remain

up since they are accessible by the management station and are in
the Normal Area, away from the fault.
Figure 5-1 APA Analysis Areas

Normal Area Fault Area Far-From-Fault Area
(APA emits no alarms)
MS N B F G H E
Normal Minor
Critical Unknown
When APA analyzes the Fault Area, it identifies node F as the root
cause. APA considers the interfaces that connect node C to node F to
be secondary failures. Similarly, the interfaces that connect node D to
node F are considered secondary failures. In this example, APA emits
only one alarm, OV_APA_NODE_DOWN F, that is visible in the top level
of the alarm browser. From the OV_APA_NODE_DOWN F alarm, you can
drill down to the following alarms:
— OOV_APA_CONNECTION_UNREACHABLE C.1 F.2

— OV_APA_CONNECTION_UNREACHABLE D.1 F.2
Note that the OV_APA_CONNECTION_UNREACHABLE alarms
identify two interface objects as the target of the alarm. The
OV_APA_NODE_DOWN and OV_APA_IF_DOWN alarms identify a single
host and interface target object respectively.
In summary, APA finds the nodes and interfaces that are in the Fault
Area, modifies the status appropriately, and sends out the
appropriate alarms. In addition, the APA finds the nodes in the
Far-From-Fault Area and adjusts the status, but does not generate
any alarms.
Chapter 5 97
APA and Dynamic View Status APA reports object status in the
Dynamic Views using the colors shown inTable 5-3.
Table 5-3 APA Status Conditions
Dynamic View
Dynamic View Status Description
Status Color
Not Monitored (tan) APA is not actively polling the object (node,
interface, connection, address, board, or
aggregated port).
Unknown (blue) APA cannot communicate with the object, or

considers the object to be a secondary
failure. APA cannot determine the status of
unreachable objects.
Disabled (brown) The object’s interface is administratively

down.
Normal (green) The object is functioning normally.
Minor (yellow) The object is functioning, but other

contained objects, such as interface,
connection, address, board, or aggregated
port objects are not functioning.
Critical (red) The object is not functioning normally.
Handling SNMP Traps from Network Devices You can configure

the SNMP agents on many network devices to send SNMP traps to an
NNM management station’s hostname or IP address. In many cases,
when APA receives traps, it initiates an immediate poll of the device
generating the SNMP trap. When APA receives any of the following
traps, it will take the associated action:
• SNMP_Link_Down or SNMP_Link_Up: APA analyzes the source’s

interfaces.
• SNMP_Cold_Start or SNMP_Warm_Start: APA analyzes the source
and its configuration.
• Cisco_Link_Down or Cisco_Link_Up: APA analyzes the source’s
interfaces and its configuration.
98 Chapter 5
• Cisco_Cold_Start or Cisco_Warm_Start: APA analyzes the

source’s interfaces.
• Cisco_HsrpStateChange: APA analyzes the HSRP group.
• Cisco_ModuleUp or CiscoModuleDown: APA analyzes the source and
its configuration.
• ciscoLS1010ChassisChangeNotification: APA analyzes the
source and its configuration.
Chapter 5 99
Understanding APA and View Status

The information contained in this section discusses how APA affects the
displayed status in various Dynamic Views.
Understanding APA and HSRP Status

APA polls HSRP routers and reports HSRP group status information.
See “Understanding HSRP View Status Information” on page 260 for
more information.
APA monitors tracked interfaces as configured on the routers contained
in the HSRP group. For example, in Figure 5-2, Router A contains an
active interface 1 in the HSRP group with a priority of 100. Router B is a
standby router in the HSRP group and contains interface 2 with a
priority of 55. If tracked interface 3 fails, interface 1’s priority falls to 50
(100 minus 50) and interface 2 becomes the active interface. The HSRP
view displays the new priority value and the interface state changes.
Figure 5-2 How APA Monitors Tracked Interfaces
Router A
Tracked Interface 3
Interface 1 Priority 50
State: Active
Server Priority 100
Router B
Interface 2
State: Standby
Priority: 55
HSRP Group
100 Chapter 5
Understanding APA, Layer 3 Polling, and Node Status

APA only updates the status of the device or interface identified as the
primary failure and synchronizes only the primary node or interface
status with the ovtopmd process and the ovw user interface. The result is
that APA only updates the ovw user interface with the primary fault
status. Once the faulty device is functioning properly, APA polls the
device and the status returns to normal.
APA considers nodes located outside of the Fault Area to be secondary
failures. APA does not update the ovw user interface with the status of
these nodes.
NOTE APA does not support IPX networked devices, IPX interfaces, or any
devices not residing in the hosts.nnm file. APA does support OAD
devices.
Understanding Board Status and the ovw User Interface

APA polls a node’s board status using SNMP as shown in Table 5-1 on
page 87. Suppose that APA finds and reports a board down, where there
are no interfaces down within the board or within the node itself. In this
example, NNM AE sets the extended topology node status to minor, and
generates an OV_APA_BOARD_DOWN alarm. However, the node status
in the ovw user interface remains normal, as the ovw user interface does
not take board status into consideration when determining node status.
Chapter 5 101
Understanding APA and Event Reduction

When you enable APA, it disables the status polling feature of the
netmon process and establishes the ovet_poll process as the polling
engine. The ovet_poll process contains alarm types beginning with
OV_APA. The following list describes the new alarms that APA may
display or log:
• OV_APA_ADDR_DOWN: APA generates this alarm when it detects

that a network entity’s address status goes from up to down.
• OV_APA_ADDR_Intermittent: APA generates this alarm when it
detects that a network address’s status has gone down and up
multiple times.
• OV_APA_ADDR_UNREACHABLE: APA generates this alarm when
it detects that an address is unreachable due to another failure, such
as the address’s interface being down.
• OV_APA_ADDR_UP: APA generates this alarm when it detects that
a network entity’s address status goes from down to up.
• OV_APA_AGGPORTCONN_DOWN: APA generates this alarm when
the aggregate port connection between two nodes is not responding
to polls and all interfaces may be down on both sides of the
connection.
• OV_APA_AGGPORTCONN_UNREACHABLE: APA generates this
alarm when the aggregate port connection between two nodes is not
responding to polls on both sides of the connection. The problem is
probably due to another entity.
• OV_APA_AGGPORTCONN_UP: APA generates this alarm when the
aggregate port connection between two nodes is responding to polls
and no interfaces are down on either side of the connection.
• OV_APA_AGGPORT_DEGRADED: APA generates this alarm when
the aggregate port connection between two nodes is responding to
polls and some of the interfaces are down.
• OV_APA_AGGPORT_DISABLED: APA generates this alarm when
the aggregate port is not responding to polls in a normal fashion.
This could be because all the interfaces’ ifAdminStatus are down or
testing. This aggregate port is the primary failure.
102 Chapter 5
• OV_APA_AGGPORT_DOWN: APA generates this alarm when the

aggregate port connection between two nodes is not responding to
polls and all interfaces may be down.
• OV_APA_AGGPORT_UNREACHABLE: APA generates this alarm
when the aggregate port connection between two nodes is not
responding to polls. The problem is probably due to another entity.
• OV_APA_AGGPORT_UP: APA generates this alarm when the
aggregate port connection between two nodes is responding to polls
and no interfaces are down.
• OV_APA_BOARD_DOWN: APA generates this alarm when it detects
that a node’s board status goes from up to down.
• OV_APA_BOARD_REMOVED: APA generates this alarm when it
detects that a node’s board has been removed.
• OV_APA_BOARD_UNREACHABLE: APA generates this alarm
when it detects that a node’s board stops responding to polls due to
another entity in the network.
• OV_APA_BOARD_UP: generates this alarm when it detects that a
node’s board status goes from down to up
• OV_APA_CONNECTION_DOWN: APA generates this alarm when it
detects that a connection’s status goes from up to down.
• OV_APA_CONNNECTION_Intermittent: APA generates this alarm
when it detects that a network connection’s status has gone down
and up multiple times.
• OV_APA_CONNECTION_UNREACHABLE: APA generates this
alarm when it detects that a connection is unreachable due to
another failure.
• OV_APA_CONNECTION_UP: APA generates this alarm when it
detects that a connection’s status goes from down to up.
• OV_APA_DEMAND_POLL: HP OpenView processes generate this
alarm when they want APA to poll a specific network entity.
• OV_APA_IF_DISABLED: This specific alarm indicates that the
interface is not responding to polls in a normal fashion. This could be
because the interface’s ifAdminStatus is down or testing.
• OV_APA_IF_DOWN: APA generates this alarm when it detects that
a network entity’s interface status goes from up to down.
Chapter 5 103
• OV_APA_IF_Intermittent: APA generates this alarm when it detects

that an interface’s status has gone down and up multiple times.
• OV_APA_IF_UNREACHABLE: APA generates this alarm when it
detects that an interface is unreachable due to another failure.
• OV_APA_IF_UP: APA generates this alarm when it detects that a
network entity’s interface status goes from down to up.
• OV_APA_Message: APA generates this alarm to reflect changes in
the network that are best communicated through text. This alarm is
mainly used for internal troubleshooting.
• OV_APA_NODE_DOWN: APA generates this alarm when it detects
that a node’s status goes from up to down.
• OV_APA_NODE_Intermittent: APA generates this alarm when it
detects that a node’s status has gone down and up multiple times.
• OV_APA_NODE_RENUMBERING: APA generates this alarm when
it detects that the interfaces or boards on a node were renumbered.
• OV_APA_NODE_RENUMBERING_FIXED: APA generates this
alarm when it detects that the interfaces or boards on a node no
longer appear to have been renumbered. This can happen after a
rediscovery, and will clear the prior
OV_APA_NODE_RENUMBERING alarm for this node.
• OV_APA_NODE_UNREACHABLE: APA generates this alarm when
it detects that a node is unreachable due to another failure, such as
and upstream node being down.
• OV_APA_NODE_UP: APA generates this alarm when it detects that
a node’s status goes from down to up.
• OV_APA_POLL: HP OpenView processes generate this alarm when
they want APA to poll a specific network entity.
• OV_APA_Statistics: APA generates this alarm to report various
execution statistics that are useful for monitoring its performance.
NOTE APA does not actually generate the IntermittentStatus alarms, they
are generated by the OV_PollerIntermittent correlators. These
correlators, if enabled, generate the OV_APA_ADDR_Intermittent,
OV_APA_IF_Intermittent, OV_APA_NODE_Intermittent, and
OV_APA_CONN_Intermittent alarms. This only happens if the
104 Chapter 5
OV_PollerIntermittent correlators are enabled, and after APA

generates multiple down events within the time window specified in
those correlators.
For specific Correlation Composer deployment information, including
how to efficiently use the HP OpenView Correlation Composer, refer to
the HP OpenView Correlation Composer’s Guide.
For more information about APA alarms, see the trapd.conf reference
page (or the UNIX manpage).
As mentioned earlier, APA generates alarms for primary failures in most
cases. This eliminates alarms from the Alarm Browser for devices that
are not known to have failed. NNM also includes several of the new APA
alarms in existing ECS correlations such as ConnectorDown and Pair
Wise correlations.
For more information about alarm reduction with NNM, see the
Managing your Network manual.
Configuration Polling and Interface Renumbering

Some device configuration activities may cause SNMP agents to
renumber SNMP MIB instance values of some Ethernet switches and
routers. These activities include the following actions:
• Moving a board from one slot to another

• Removing a board
• Adding a new board
• Removing the supervisor board in a dual supervisor board system
• Power cycling a switch or router
APA collects and stores MIB information from Ethernet switches and
routers. This includes information from MIB instances such as ifAlias,
ifName, ifDescr, and ifPhysAddress.
APA checks to see if this indexed information has changed since the last
configuration check. Any deviation from the last ifAlias, ifName,
ifDescr, or ifPhysAddress values can be a symptom caused by a
device’s interfaces being renumbered.
Chapter 5 105
If APA determines that interface renumbering activity has occurred, it

emits an OV_APA_NODE_RENUMBERING alarm, and displays a message in
the Discovery Status area of Home Base. This message tells you the
zone in which the renumbering occurred. You need to initiate a new
discovery for this zone in order to update the extended topology database
with the new ifIndex value information.
If you want to see more information, APA logs the details about each
OV_APA_NODE_RENUMBERING alarm in the following file:
• Windows:%OV_PRIV_LOG%\ovet_poll.log.txt
• UNIX: $OV_PRIV_LOG/ovet_poll.log.txt
See “Discovering Devices in a Single Zone” on page 38 for more
information.
NOTE You can update the status of a device and check to see if interface
renumbering activity has occurred by using the following procedure:
1. Select a device from one of NNM’s Dynamic Views.

2. Right-click the mouse and select APA Status Poll.
If APA detects that interface renumbering occurred, it will display an
OV_APA_NODE_RENUMBERING alarm in the Alarm Browser.
Once Extended Topology completes a new discovery for this zone, APA
removes the OV_APA_NODE_RENUMBERING alarm from the alarm browser.
See the trapd.conf reference page (or the UNIX manpage) for more
information.
Disabling or Adjusting the Frequency of Configuration Polling

If you do not want to track interface renumbering for your switches or
routers, or want to adjust the configuration polling interval, use the
following procedure:
1. Create a backup copy of the paConfig.xml file prior to making any

changes.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the following polling interval text:
106 Chapter 5
<defaultParameters>
<parameterList>
<parameter>
<name>interval</name>
<title>Interval to Perform Config Poll Device</title>
<description>
The interval which the device will be config polled in seconds.
</description>
<varValue>
<varType>Integer</varType>
<value>86400</value>
</varValue>
</parameter>
<parameter>
<name>enable</name>
<title>Enable config poll for device</title>
<description>
Enable/Disable config poll of a device
</description>
<varValue>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
• If you want to adjust the configuration polling frequency, modify

the bold number to the desired number of seconds.
• If you want to completely disable the configuration polling,
change the bold true to false.
• Windows: %OV_BIN%\ovstop -c ovet_poll
Chapter 5 107
• UNIX: $OV_BIN/ovstop -c ovet_poll

• Windows: %OV_BIN%\ovstart -c ovet_poll

• UNIX: $OV_BIN/ovstart -c ovet_poll
108 Chapter 5
Enabling and Disabling APA
Enabling and Disabling APA

If you choose to have APA monitor your general IPv4 interfaces, it
disables the polling feature of the netmon process and enables APA.
NOTE APA takes its polling list exclusively from the extended topology, which
includes general IPv4 interfaces discovered by the netmon process and
placed in the hosts.nnm file. You need to make sure that your important
nodes are not blocked by the bridge.noDiscover file.
• As Administrator or root, run the following script to enable APA

polling and disable status polling using the netmon process:
— Windows:
%OV_BIN%\ovet_apaConfig.ovpl -enable APAPolling
— UNIX:
$OV_BIN/ovet_apaConfig.ovpl -enable APAPolling
• As Administrator or root, run the following script to disable APA
and enable status polling using the netmon process:
— Windows:
%OV_BIN%\ovet_apaConfig.ovpl -disable APAPolling
— UNIX:
$OV_BIN/ovet_apaConfig.ovpl -disable APAPolling
NOTE You may choose to enable APA status polling, then disable it later. If you
do this, APA continues to monitor addresses that you designate as
belonging to an OAD, query HSRP routers, and report HSRP group
status information
See the ovet_apaConfig.ovpl reference page (or the UNIX manpage)

Chapter 5 109
Configuring APA
Configuring APA
You may need to adjust APA to optimize it for your particular
environment. Prior do making any APA adjustments, it is a good idea to
understand how APA is performing.
Understanding APA Polling Statistics

NNM collects information that shows how APA is performing. From
Home Base, select the Polling/Summary Analysis tab. The resulting
view shows information from the Active Problem Analyzer (and not from
NNM’s netmon process). APA statistics are collected on five-minute
intervals. The statistics are as follows:
• Active Analyzer Tasks: This represents the number of polling results

that are currently under analysis. This number should trend toward
zero when the network is stable. If this number never trends toward
zero, you may need to increase the number of threads in the status
analyzer thread pool. See “Adjusting the Number of Threads in the
Status Analyzer Thread Pool” on page 116.
If the number of Active Analyzer Tasks begins to steadily
increase, then you are experiencing network problems. Look in the
Alarm Browser for an alarm that indicates the root cause of your
network problem.
• Waiting Poller Tasks: This represents the maximum number of
polling tasks that were waiting to be completed during the last
polling interval. Track the quantity of Waiting Poller Tasks that
is normal for your environment. If this number begins to increase, it
indicates that the APA poller is unable to keep up with the polling
load.
To remedy this, review the following list and make adjustments if
necessary.
— Make sure NNM and Extended Topology are only monitoring

your critical devices.
— Increase the default polling interval. See “Changing the Default
Polling Interval” on page 113 for more information. Do not adjust
this number too low, as that can create performance problems
when large quantities of network problems occur.
110 Chapter 5
Configuring APA
— Increase the polling intervals of any of the device classes. See

“Changing the Polling Interval by Device Class” on page 114 for
more information. Do not adjust this number too low, as that can
create performance problems when large quantities of network
problems occur.
— Increase the polling engine thread pool size. See “Adjusting the
Number of Threads in the Polling Engine Thread Pool” on
page 117 for more information. Do not adjust this number too
low, as that can create performance problems when large
quantities of network problems occur.
• Addresses Polled (ICMP): This represents the number of addresses
that were pinged during the last statistics reporting interval. Track
the quantity of Addresses Polled (ICMP) that is normal for your
environment. This number is an indication of how busy your APA
polling engine is. Make sure NNM and Extended Topology are only
monitoring your critical devices.
• Interfaces Polled (SNMP): This represents the number of interfaces
that were queried for status through SNMP during the last reporting
interval. Track the number of Interfaces Polled (SNMP) that is
normal for your environment.This number is an indicator of how
busy your APA polling engine is. Make sure NNM and Extended
Topology are only monitoring your critical devices.
• Waiting Analyzer Tasks: This represents the number of polling
results waiting to be analyzed. When a series of failures occur, this
number rises. If this number continues to rise over several polling
cycles, it indicates a serious issue in the network. A temporary surge,
which then trends toward zero, is normal when a fault or change
occurs.
• HSRP Groups Polled: This represents the number of HSRP groups
that were queried for status during the last reporting interval. Track
the HSRP Groups Polled number that is normal for your
environment. This number is an indication of how busy your APA
monitoring your critical HSRP devices.
• Boards Polled: This represents the number of boards that were
queried for status through SNMP during the last reporting interval.
Track the number of Boards Polled (SNMP) that is normal for your
Chapter 5 111
Configuring APA
environment.This number is an indicator of how busy your APA

monitoring your critical devices.
Adjusting APA Polling Parameters

APA allows you to manually adjust the status polling frequencies. You
can adjust polling intervals based upon extended topology filters. Using
this method, you can apply configuration attributes based upon the
capability, or class, of a device.
NOTE You must have a basic understanding of XML concepts, terms, and
syntax before attempting to edit the paConfig.xml file. Without that
knowledge, it is very easy to make serious errors. It is assumed that you
have adequate expertise in XML terminology and syntax, as this book
does not define XML terms or explain XML tagging or syntax.
You can make modifications to APA polling frequencies. However there

are only a few parameters you will want to modify. The following file
contains these adjustable parameters:
• Windows: %OV_CONF%\nnmet\paConfig.xml
• UNIX: $OV_CONF/nnmet/paConfig.xml
The paConfig.xml file contains the following sections:
• Polling Engine
You can easily recognize this section, as the following tags begin the
Polling Engine section of the xml file:
<subSystemConfig>
<name>PollingEngine</name>
<title>Polling Engine</title><subSystemConfig>
• Status Analyzer
Status Analyzer section of the xml file.
<subSystemConfig>
<name>StatusAnalyzer</name>
112 Chapter 5
Configuring APA
<title>Status Analyzer</title>
• Talker
Talker section of the xml file.
<subSystemConfig>
<name>Talker</name>
<title>Talker SubSystem</title>
• StatusBridge
Status Bridge section of the xml file.
<subSystemConfig>
<name>StatusBridge</name>
<title>Status Bridge</title>
By modifying this file, you can adjust global polling parameters as well
as the polling frequency of classes of devices such as routers, switches,
and end nodes.
Changing the Default Polling Interval

Suppose you want to modify the default polling interval for devices not
belonging to a specific device class. To do this, use the following
procedure:

changes.
CAUTION Be sure to keep careful records and backups of any and all changes to
the paConfig.xml file.

3. Look for the following polling interval text:
<classSpecificParameters>

<defaultParameters>
Chapter 5 113
Configuring APA
<parameterList>
<parameter>
<title>Interval to Poll Device</title>
<description>
The interval which the device will be polled in seconds.
</description>
<varValue>
<value>300</value>
</varValue>
</parameter>
Change the bold number to the number of seconds you want APA to
wait before again polling devices that do not belong to any defined
device class. Make sure to save your changes.


This applies your changes to the APA polling process.
Changing the Polling Interval by Device Class

The paConfig.xml file references filters that allow you to modify polling
intervals by device class. The polling interval of a device class takes
precedence over the default polling interval discussed in “Changing the
Default Polling Interval” on page 113.
Suppose you want to modify the router polling frequency. To do this, use

changes.
114 Chapter 5
Configuring APA

3. Look for the isRouter filter text that looks as follows:
<classSpecification>
<filterName>isRouter</filterName>
<parameterList>
<parameter>
<description>
</description>
<varValue>
<value>300</value>
</varValue>
</parameter>
Modify the bold number to the number of seconds you want APA to
wait before repolling devices that pass the isRouter filter. Make
sure to save your changes.


This applies your changes to the APA polling process.
Chapter 5 115
Configuring APA
The filter name is shown in bold print in the above example. Using a
similar procedure, you can modify the polling frequency for devices
that pass other topology filters. Look for filters with the following
names:
• isSwitch
• isEndNode
Adjusting the Number of Threads in the Status Analyzer Thread

Pool
You can adjust the number of threads in the status analyzer thread pool.
This increases the number of threads servicing the status analyzer. This
could improve the status analyzer performance, however increasing this
number increases the system resources that APA consumes.
To increase the number of threads in the status analyzer thread pool, use

changes.

3. Look for the following analysis engine thread pool text:
<parameter>
<name>statusAnalyzerThreadPoolSize</name>
<title>Status Analyzer Thread Pool Size</title>
<description>
This parameter specifies how many threads are in the status
analyzer thread pool. Increasing the value of this parameter,
increases the amount of analysis parallelism and the amount of
system resources consumed (e.g. number of file descriptors).
Increasing the value of this parameter may or may not increase
status engine performance.
116 Chapter 5
Configuring APA
</description>
<varValue>
<value>10</value>
</varValue>
</parameter>
Change the bold number to the number of threads you want in the
analysis thread pool. Make sure to save your changes.


Adjusting the Number of Threads in the Polling Engine Thread

Pool
You can adjust the number of threads in the polling engine thread pool.
This increases the number of threads servicing fault analysis. This could
improve polling engine performance, however, increasing this number
increases the system resources that APA consumes.
To increase the number of threads in the polling engine thread pool use

changes.

3. Look for the following polling engine thread pool text:
<parameter>
Chapter 5 117
Configuring APA
<name>PollingEngineThreadPoolSize</name>
<title>Polling Engine Thread Pool Size</title>
<description>
This parameter specifies how many threads are in the polling
engine thread pool. Increasing the value of this parameter,
increases the amount of pooling parallelism and the amount of
system resources consumed (e.g. number of file descriptors).
Increasing the value of this parameter may or may not increase
polling engine performance.
</description>
<varValue>
<value>16</value>
</varValue>
</parameter>
Change the bold number to the number of threads you want in the
polling engine thread pool. Make sure to save your changes.


Configuring APA to Display Alarms from Important Nodes

APA does not emit failure alarms for devices that are located in the
Far-From-Fault area. This means that if a failure occurs, APA will not
generate any failure alarms for these devices.
APA emits secondary failure alarms for devices that are not located in
the Far-From-Fault area and are not considered primary failures. APA
emits these alarms as OV_APA_alarmname_Unreachable alarms and
correlates them beneath the primary failure alarm.
118 Chapter 5
Configuring APA
If your network contains important devices that are critical to your

environment, you may want to configure APA to always send
uncorrelated alarms associated with these devices to the alarm browser.
To configure APA to emit the alarms for these important nodes, and
display them in the Alarm Browser as primary failure alarms, you can
designate a list of important nodes. This important node list enables APA
to generate the OV_APA_NODE_UNREACHABLE and
OV_APA_CONNECTION_UNREACHABLE alarms for these devices, and display
them as primary failure alarms in the Alarm Browser.
NOTE Only add the most important devices, those devices that are critical to
your environment, to your important nodes list. Adding smaller
quantities of devices to this list consumes fewer computer resources.
Use the following procedure to designate these important nodes:
1. Make a backup copy of the following file:
• Windows: %OV_CONF%\nnmet\topology\filter/MyHostID.xml
• UNIX: $OV_CONF/nnmet/topology/filter/MyHostID.xml
2. As Administrator or root, edit the MyHostID.xml file.
3. Look for the last line containing the following tags:
<IPv4><address>0.0.0.0</address></IPv4>
4. Change the text shown in bold in the previous step to match your
needs using the syntax in one of the following examples. In these
examples, x, y, and z represent replaceable IP address fields:
<IPv4><address>x.y.z.*</address></IPv4>
<IPv4><address>x.y.z.1-99</address></IPv4>
Make sure to save your changes.
5. Execute, as Administrator or root, ovstop ovet_poll.
6. Execute, as Administrator or root, ovstart ovet_poll.
Chapter 5 119
Configuring APA
Using Topology Filters

The paConfig.xml file uses extended topology filters to limit the devices
to which you make polling configuration changes. To get a listing of the
filter names, use the ovet_topodump.ovpl -lfilt command. To verify
the nodes selected by a filter, run the ovet_topodump.ovpl -node
-filt filter_name. See the ovet_topodump.ovpl reference page (or the
Implementing a Topology Filter

The Polling Engine subsystem in the paConfig.xml file contains a Polling
Settings configGroup that includes polling configuration parameters.
Within this configGroup, the set of parameters located beneath the
<classSpecific Parameters> xml tag control how APA polls devices if they
do not pass any of the extended topology filters within the configGroup
list.
If a device belongs to any of the device classes specified beneath the
<classSpecification> xml tag, then APA polls the device according to
the parameters contained within the specified class.
For example in the xml listing below, the first referenced filter, isRouter,
contains a polling interval integer, shown in bold, that you can adjust.
<classSpecifications>
<filterName>isRouter</filterName>
<parameterList>
<parameter>
<description>
</description>
<varValue>
<value>300</value>
</varValue>
</parameter>
120 Chapter 5
Configuring APA
<parameter>
<name>snmpEnable</name>
<title>Enable polling via SNMP</title>
<description>
Enable/Disable polling of a device via SNMP.
</description>
<varValue>
<value>true</value>
</varValue>
</parameter>
You can use extended topology filters to add device classes into the
paConfig.xml file to categorize devices in your environment.
TIP You may find some basic knowledge of XML to be helpful when making
changes to the paConfig.xml file. Changes you make that are not
discussed here are risky and unsupported.
For example, if you want to create one location in the paConfig.xml file
to adjust the APA polling of your HP ProCurve devices, use the following
procedure:
1. Run the ovet_topodump.ovpl -lfilt command to see a list of the

existing filters. The output will look something like this:
APANoPollNodes
AccessPort
AdminDownInterface
AdminUpOrTestInterface
AlcatelDevices
AllBoards
AllVirtualAddress
AvayaIptDevices
BayDevices
CiscoDevices
CiscoRouter
ConnectedEndNode
ConnectedIF
Chapter 5 121
Configuring APA
ConnectedIFInInfrDev
ConnectedNode
ExceptionInfrDev
ExceptionNode
ExtremeDevices
HasBoards
HSRPCoreGroup
IFConnectedToEndNode
IfTypeFilter
ImportantNodes
InfrDev
InterfaceInEndNode
InterfaceInInfraDev
InterfaceInRouter
InterfaceInSwitch
InterfaceWithMPLSName
InterfacesWithAnycastAddrs
InterfacesWithDupAddrs
NoPingAddresses
NodeWithDownInterface
NodeWithMPLSId
NodesWithBoards
NodesWithRhinoMIB
NodesWithStackMIB
NonSnmpNode
NonSnmpSwitch
NortelDevices
NotConnectedIF
NotConnectedNode
NotConnectedSnmpRouter
NotConnectedSnmpSwitch
ProcurveDevices
RHINOMIB
STACKMIB
SnmpEndNode
SysName
ThreeComDevices
TrunkPort
UnconnectedAdminDownRouterIF
UnconnectedAdminDownSwitchIF
UnconnectedAdminUpOrTestRouterIF
UnconnectedAdminUpOrTestSwitchIF
UnconnectedEndNode
WanIF
isATM
isCDP
122 Chapter 5
Configuring APA
isEndNode
isFrameRelay
isHSRP
isIpPhone
isPartOfAggregatedIF
isRouter
isSnmp
isSwitch
slowIfSpeeds
vlanTrunkPort
wanIfTypes
2. Run the ovet_topodump.ovpl -node -filt ProcurveDevices

command to get a list of all of the ProCurve devices in your
environment.
changes.
4. If the list of devices that this command produces contains the

devices you want to manage as a class, complete this step. As
Administrator or root, open the paConfig.xml file and find the
following xml tags.

5. Add the following filter text beneath the bold xml tag shown above.
Do not place the new text within the text of any of the existing filters.
The filters you reference in paConfig.xml are prioritized from the top
down, so the order in which you add filters matters. Make sure you
add your filters before or after other filters as appropriate.
<filterName>ProcurveDevices</filterName>
<parameterList>
<parameter>
Chapter 5 123
Configuring APA
<description>
</description>
<varValue>
<value>300</value>
</varValue>
</parameter>
<parameter>
<description>
</description>
<varValue>
<value>true</value>
</varValue>
</parameter>
</parameterList>
</classSpecification>

124 Chapter 5
Configuring APA
Suppress or Allow APA Status Polling

You can configure NNM to allow or suppress the APA status polling of
objects by using the ovet_toposet command.
Table 5-4 shows the effect on objects when allowing or suppressing APA
status polling for nodes, boards, interfaces, or addresses.
Table 5-4 Expected Object Status Behavior when Suppressing or Allowing
APA Status Polling
Allowed or
Suppressed APA APA Polling Behavior
Polling of Object
Node Allows or suppresses APA status polling for the boards

associated with a node, all of the interfaces associated with
each board, and the addresses associated with each
interface.
Board Allows or suppresses APA status polling for the interfaces

associated with a board, and the addresses associated with
each interface.
Interface Allows or suppresses APA status polling for the addresses

associated with an interface.
Address Allows or suppresses APA status polling for the specified

address.
IMPORTANT If you use the ovet_toposet command to allow an object to be polled,

there are other parameters within the paConfig.xml file that could
override the ovet_toposet command, and suppress the polling of the
targeted object. See “Controlling Other APA Polling Types” on page 127
You can find the parameters used in the ovet_toposet command in the
board and interface information included in NNM AE’s Dynamic Views.
See the ovet_toposet reference page (or the UNIX manpage) for more
information.
Chapter 5 125
Configuring APA
NOTE APA propagates the status of objects considered to be the root cause of a
fault to ovw.
APA may propagate the status of unpolled interfaces, objects not
considered to be the root cause of a fault, or objects that do not exist in
the extended topology as having a normal or unknown status in ovw.
126 Chapter 5
Controlling Other APA Polling Types

The Polling Engine section of the paConfig.xml file contains the
configuration parameters for the ovet_poll process.This chapter only
explains a few of the modifications you can make to the Polling Engine
and Status Analyzer. Do not make adjustments to the Talker or Status
Bridge sections of the paConfig.xml file.
TIP You may find some basic knowledge of XML to be helpful when making
changes to the filename.xml files discussed in this section. Changes you
make that are not discussed here are risky and unsupported.
You may need to modify the way APA polls devices and interfaces. To do
this, there are parameters you can modify in the paConfig.xml file.
Below are some examples showing how to modify APA polling.
Enable or Disable Global HSRP Group Polling

You can enable or disable global parameters in the paConfig.xml file
that override any class-based parameters. For example, to enable or
disable global HSRP group polling, use the following procedure:

changes.

3. Look for the following HSRP group polling enabling text:
<parameter>
<name>HSRPPollingEnable</name>
<title>Enable HSRP Polling</title>
<description>
Chapter 5 127
Enable/Disable polling of HSRP Groups.

</description>
<varValue>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable the global HSRP
polling or true if you want to enable the global HSRP polling. Make


Enable or Disable HSRP Polling for Devices not

Belonging to a Device Class
You may want to modify parameters for devices not belonging to a device
class. For example, to enable or disable HSRP group polling for routers
and interfaces that do not belong to a device class, use the following
procedure:

changes.

3. Look for the following HSRP group polling enabling text:
128 Chapter 5
<parameter>
<name>hsrpEnable</name>
<description>
Enable/Disable polling of HSRP Group. If the router/interface
does not have hsrp enabled then setting this parameter to
true does nothing.
</description>
<varValue>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable HSRP polling or
true if you want to enable HSRP polling. This parameter enables or
disables HSRP polling for routers, ports, and interfaces. Make sure to
save your changes.


NOTE If you do not want APA polling your HSRP groups, run
setupExtTopo.ovpl and answer no when asked if you want to enable
HSRP polling. You must run setupExtTopo.ovpl as Administrator or
root.
Chapter 5 129
Enable or Disable SNMP Polling of Devices not

This an example of adjustable parameters for devices not belonging to a
device class. For example, to enable or disable SNMP polling for devices
that do not belong to a device class, use the following procedure:

changes.

3. Look for the following SNMP polling enabling text:
<defaultParameters>
<parameterList>
<parameter>
<description>
</description>
<varValue>
<value>300</value>
</varValue>
</parameter>
<parameter>
130 Chapter 5

<description>
</description>
<varValue>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable SNMP polling
for devices that do not belong to a device class, or true if you want to
enable SNMP polling for devices that do not belong to a device class.


Enable or Disable ICMP Polling of Devices not

This an example of adjustable parameters for devices not belonging to a
device class. For example, to enable or disable ICMP polling for devices
that do not belong to a device class, use the following procedure:

changes.
Chapter 5 131
2. As Administrator or root, edit the paConfig.xml file.Create a

backup copy of the paConfig.xml file prior to making any changes.
3. Look for the following SNMP polling enabling text:
<defaultParameters>
<parameterList>
<parameter>
<description>
</description>
<varValue>
<value>300</value>
</varValue>
</parameter>
<parameter>
<description>
</description>
<varValue>
<value>true</value>
</varValue>
</parameter>
<parameter>
132 Chapter 5
<name>pingEnable</name>
<title>Enable polling via ICMP</title>
<description>
Enable/Disable polling of a device via ICMP.
</description>
<varValue>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable ICMP polling for
devices that do not belong to a device class, or true if you want to
enable ICMP polling for devices that do not belong to a device class.


Enable or Disable SNMP Polling for Unconnected

Switch Ports
There are times when some devices will not be in the extended topology
database, or will not otherwise connect correctly. An example of this is if
Extended Topology discovers information from an OAD environment, but
cannot talk to some of the end nodes using SNMP. The result is confusion
about whether there are any nodes connected to certain ports on a
switch.
APA provides a solution for this problem. APA decides whether to poll a
device using attributes from the node and interface. For example, APA
knows if an interface’s port is connected to another node in the extended
Chapter 5 133
topology and knows the class of the device it is polling. You can configure
APA to SNMP poll switch ports that are either known to be connected to
another node in the extended topology or have an ifAdminStatus of up.
This solution involves editing the paConfig.xml file. This solution
assumes that you manually configure the ifAdminStatus parameter on
the switches you want to poll using SNMP.
To implement this solution, use the following procedure:
1. Manually configure the ifAdminStatus parameter on your switches.

For example, if you want APA monitor a switch port using SNMP,
you must manually set its ifAdminStatus to up.
2. Make sure you have APA enabled.
changes.
4. As Administrator or root, edit the following file:
5. Search for UnconnectedAdminUpOrTestSwitchIF
You should see the following:
<filterName>UnconnectedAdminUpOrTestSwitchIF</filterName>
<parameterList>
<parameter>
<description>
</description>
134 Chapter 5
<varValue>
<value>false</value>
</varValue>
</parameter>
6. Modify the bold false to true. Make sure to save your changes.


Disable ICMP Polling for ISDN, SLIP, and Other

ifTypes
Suppose you want to stop APA from using ICMP polling for IANA
ifTypes ISDN (ifType=20) and SLIP (ifType = 28). To do this, you can use
an existing topology filter designed for ISDN and SLIP ifTypes. If
desired, you can expand the filter to include more ifTypes. To enable this
feature, complete the following procedure:
1. Create a backup copy of the following file:
• Windows:
%OV_CONF%\nnmet\topology\filter\TopoFilters.xml
• UNIX: $OV_CONF/nnmet/topology/filter/TopoFilters.xml
2. As Administrator or root, edit the TopoFilters.xml file.
Look for the following text:
<interfaceAssertion name="IfTypeFilter" title="IfTypeFilter"
description="Interface are of a particular ifType">
<operator oper="OR">
<attribute>
Chapter 5 135
<ifType>28</ifType>
</attribute>
<attribute>
<ifType>20</ifType>
</attribute>
</operator>
</interfaceAssertion>
NOTE Notice the text in the bold font that sets the ifTypes within this
filter. If you follow the rest of this procedure, APA will stop using
ICMP polling for ISDN, SLIP, or other IANA ifTypes that you
specify.
3. If you want APA to stop using ICMP polling for additional IANA
ifTypes, add all of these new ifTypes using the same syntax shown
in the above program listing. Add these additional ifTypes as shown
below:
<attribute>
<ifType>first additional ifType</ifType>
</attribute>
<attribute>
<ifType>next additional ifType</ifType>
</attribute>
4. Use the ovet_topodump.ovpl -lfilt command to check the syntax
of any additions you make to the TopoFilters.xml file.
NOTE If the ovet_topodump.ovpl -lfilt command generates any errors,

remove the syntax errors that you created in the TopoFilters.xml
file. If you cannot find the errors you made, replace the
TopoFilters.xml file with the backup copy you made in step 1 and
begin again.
136 Chapter 5
5. Create a backup copy of the following file prior to making any

changes.
7. Look for the following text:

8. Remove the bold text shown at both the top and the bottom of the
above program listing. Make sure to save your changes.
9. Run the ovet_topodump.ovpl -if -filt IFTypeFilter command
to get a list of all of the ProCurve devices in your environment.
Chapter 5 137


Disable APA from Polling Specific Nodes

Suppose you want to stop APA from polling specific nodes. To do this, use

changes:
• Windows:
%OV_CONF%\nnmet\topology\filter\APANoPollNodes.xml
• UNIX:
$OV_CONF/nnmet/topology/filter/APANoPollNodes.xml
2. As Administrator or root, edit the APANoPollNodes.xml file.
<HostIDs xmlns="http://www.hp.com/openview/NetworkTopology/TopologyFilter"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://
www.hp.com/openview/NetworkTopology/TopologyFilter
HostIDFile.xsd">









138 Chapter 5
<IPv4><address>0.0.0.0</address></IPv4>
</HostIDs>
4. Add the IP addresses you do not want APA to poll by using the
syntax and associated xml tags shown in the bold font in the
program listing shown above. You can use wildcards or ranges as
shown in the examples. Make sure to save your changes.
5. Create a backup copy of the following file:
<!-- Uncomment this class specification to use the APANoPollNodes
filter. Users should edit the APANoPollNodes.xml
file to specify what nodes are in the filter.
<filterName>APANoPollNodes</filterName>
<parameterList>
<parameter>
<description>
</description>
<varValue>
</varValue>
</parameter>
<parameter>
Chapter 5 139
<description>
</description>
<varValue>
</varValue>
</parameter>
<parameter>
<name>hsrpEnable</name>
<description>
Enable/Disable polling of HSRP Group. If the
router/interface does not have hsrp enabled then setting
this parameter to true does nothing.
</description>
<varValue>
</varValue>
</parameter>
</parameterList>
<!-- Uncomment this class specification to use the APANoPollNodes
filter. Users should edit the APANoPollNodes.xml
file to specify what nodes are in the filter.
140 Chapter 5
<filterName>APANoPollNodes</filterName>
<parameterList>
<parameter>
<name>enable</name>
<title>Enable config poll for device</title>
<description>
Enable/Disable config poll of a device
</description>
<varValue>
</varValue>
</parameter>
</parameterList>
</classSpecifications>


Chapter 5 141
Disable APA from Using ICMP to Poll Specific

Addresses
Suppose you want to stop APA from using ICMP to poll specific
addresses. To do this, you can use an existing topology filter by
completing the following procedure:

changes:
• Windows:
%OV_CONF%\nnmet\nnmet\topology\filter\TopoFilters.xml
• UNIX: $OV_CONF/nnmet/topology/filter/TopoFilters.xml
2. As Administrator or root, edit the TopoFilters.xml file.
<addressAssertion name="NoPingAddresses" title="No Ping Addresses"
description="A
ddresses which should not be pinged">
<operator oper="OR">
<attribute>
<IPAddress>
<IPv4>
<address>15.2.112.22</address>
/IPv4>
</IPAddress>
</attribute>
<attribute>
<IPAddress>
<IPv4>
<address>15.2.119.52</address>
</IPv4>
</IPAddress>
</attribute>
<attribute>
142 Chapter 5
<IPAddress>
<IPv4>
<address>10.0.0.*</address>
</IPv4>
</IPAddress>
</attribute>
<attribute>
<IPAddress>
<IPv4>
<address>10.0.0.0-66</address>
</IPv4>
</IPAddress>
</attribute>
</operator>
</addressAssertion>
</filters>
4. Modify the text shown in the bold font in the program listing shown
above. Add all of the IP addresses you want to stop APA from polling
(using ICMP). You can use wildcards or ranges as shown in the above
examples.
5. There are several working examples in the program listing above. If
you need to remove any of these working examples, remove all of the
text between the <attribute> and </attribute> tags. You will
need to remove the <attribute> and </attribute> tags as well. If
you need to add more addresses, use the syntax shown below. Make
<attribute>
<IPAddress>
<IPv4>
<address>address syntax</address>
</IPv4>
</IPAddress>
Chapter 5 143
</attribute>
6. Use the ovet_topodump.ovpl -lfilt command to check the syntax
of any additions you make to the TopoFilters.xml file.
NOTE If the ovet_topodump.ovpl -lfilt command generates any errors,

correct any syntax errors that you created in the TopoFilters.xml file.
If you cannot find the errors you made, replace the TopoFilters.xml
file with the backup copy you made in step 1 and begin again.

changes:
<!-- Uncomment this class specification to disable ICMP (ping)
for NoPingAddresses filter. Users should edit the
TopoFilters.xml addresses to include in the filter.
<filterName>NoPingAddresses</filterName>
<parameterList>
<parameter>
<description>
</description>
<varValue>
</varValue>
144 Chapter 5
</parameter>
</parameterList>


Chapter 5 145
Frequently Asked Questions

When enabled, APA replaces several features normally provided by the
netmon process. Below is a list of frequently asked questions and
answers that describe APA features.
How does APA affect NNM performance?
Answer: APA is multi-threaded, suppresses secondary alarms, and
generates one alarm for a failure’s root cause in most cases. This results
in a faster polling engine.
How does APA derive node and interface status?
Answer: APA uses ICMP to determine address status. It separates
interfaces from addresses in order to monitor interface status using both
ICMP or SNMP.
What does APA do in an HSRP environment?
Answer: Extended Topology with the Advanced Routing SPI queries the
devices that participate in an HSRP group. These devices must support
the HSRP protocol. APA retrieves specific HSRP MIB values that provide
the actual HSRP roles and responsibilities of each device in the group.
Using this information, APA generates HSRP alarms when HSRP status
changes occur.
Does APA consider Spanning Tree Protocol (STP) when
analyzing failures?
Answer: APA considers the effects of the STP when diagnosing the root
cause of unresponsive interfaces. It suppresses transient failures due to
spanning tree reconvergence which results in fewer transient alarms.
Does APA consider meshed switches when diagnosing network
faults?
Answer: APA analyzes meshed environments when calculating the root
cause of unresponsive interfaces.
Does APA use any of the layer 2 information from the netmon
process?
Answer: APA uses the layer 2 connectivity information stored in the
extended topology database. It is important to remember that APA still
relies on the netmon process for device discovery.
146 Chapter 5
How do you configure SNMP information for APA?

Answer: APA uses the same SNMP configuration information as the
netmon process.
Can APA ping the virtual IP address?
Answer: This is not supported in this release.
How does interact with incremental discovery and zones?
APA becomes aware of any of the topology changes Extended Topology
discovers. For example, after Extended Topology initiates and completes
a discovery, or you tell Extended Topology to discover a specific zone and
it completes that discovery, APA immediately begins using this new
information.
Chapter 5 147
148 Chapter 5
6 Syslog Integration
Chapter 6 149
Syslog Integration
Introducing the Syslog Integration Functionality
Introducing the Syslog Integration

Functionality
The Syslog Integration functionality enables the management of
network equipment from syslog messages. Certain types of network
equipment do not have SNMP traps nor supporting MIBs for all error
and warning conditions. For operators who require managing these
conditions, the Syslog Integration functionality provides the ability to
map syslog messages into SNMP traps for presentation or analysis.
Network Node Manager Advanced Edition includes out-of-the-box
conditions for which syslog messages are mapped to SNMP traps. You
can add new conditions through the NNM Syslog Trap Mapping
Configuration interface or the HP OpenView Operations message source
template configuration windows, depending on your deployment mode.
Syslog Integration functionality is available with Network Node
Manager Advanced Edition (NNM AE). Syslog Integration is also
available with HP OpenView Operations with NNM, version 8.0. Syslog
Integration must be configured on an NNM management station
running an UNIX® operating system. See the Release Notes for
supported software versions.
Syslog Integration Deployment Options

There are two deployment options available to you when using the
Syslog Integration functionality.
• NNM standalone
• OpenView Operations (OVO) with NNM
NOTE For the OVO with NNM deployment option, two scenarios are
allowed. The Syslog Integration functionality resides on a NNM
management station co-located with OVO or the Syslog Integration
functionality resides on a remote NNM management station (not
co-located with OVO).
150 Chapter 6
Syslog Integration
NNM Standalone Configuration

The NNM standalone configuration consists of deploying an HP
OpenView Operations (OVO) agent on the NNM management station. In
short, the embedded OVO agent uses preconfigured templates to parse
incoming syslog messages matching a certain pattern. The matched
syslog messages are mapped to SNMP traps and forwarded to NNM to be
displayed in the NNM alarm browser. See Figure 6-1 on page 152 for an
illustration.
In this approach, the following components comprise the heart of the
architecture:
• The embedded OVO agent

When Syslog Integration is configured, an OVO agent is installed on
the NNM management station. Part of the embedded OVO agent is
the logfile encapsulator that is responsible for listening for syslog
events from logfiles. The logfile encapsulator filters and formats
syslog events according to information in configured templates. The
logfile encapsulator then forwards relevant information in the form
of messages to an NNM background process, syslogTrap, which
maps the syslog messages into SNMP traps.
• The NNM management station
When Syslog Integration is configured, the NNM management
station receives formatted syslog messages from the embedded OVO
agent. syslogTrap, a background process on the NNM management
station, maps the syslog messages to OpenView SNMP traps. This
process registers with the OVO agent at the message stream
interface and filters all messages of message type NNMsyslog_.
The events generated from syslogTrap are of type OV_Syslog_ and
have the same general format:
— A unique enterprise-specific ID to identify the syslog message.

— An OpenView application name varbind identifying the source as
syslogTrap.
— A varbind identifying the source of the event.
— Varbinds identifying the card/port/interface, status, and so on, as
appropriate.
— A varbind that encapsulates the original message.
Chapter 6 151
Syslog Integration
The SNMP traps are then sent to the NNM postmaster process, pmd,
where the traps can participate in correlation or analysis. For
example, when the NNM Smart Plug-in for LAN/WAN Edge is
installed, it provides advanced correlators for frame relay traps and
syslog messages. pmd forwards the formatted syslog messages to the
NNM alarm browser.
• NNM alarm browser
Processed syslog messages are displayed in the Status Alarm
category of the NNM alarm browser.
Figure 6-1 shows the flow of events for the NNM standalone
configuration. This illustration assumes that the router has been
configured to forward syslog events to the NNM management station.
Figure 6-1 Flow of Events for NNM Standalone Configuration
NNM alarm
browser
NNM Management Station OV alarm

pmd
OVO Agent OV SNMP trap
Syslog to syslogTrap
NNM
template
Enabled
Template
and Agent
MSI
syslog message
ASCII Logfile OVO-like message
syslogd logfile Encapsulator
router
152 Chapter 6
Syslog Integration
To modify the Syslog to NNM template, use the NNM Syslog Trap
Mapping Configuration Interface as described on page 155.
OpenView Operations with NNM ConfigurationSS

The OVO with NNM configuration option consists of deploying HP
OpenView Operations with Network Node Manager. Two deployment
approaches exist for this configuration option. First, the NNM
management station on which the Syslog Integration functionality is
installed resides on the OVO server. Optionally, the Syslog Integration
functionality resides on a NNM management station separate from the
OVO server system.
With either approach, you install an OVO agent on the NNM
management station from the OVO server and use the OVO tools to
configure the OVO agent to process syslog events.
This approach is similar to the NNM standalone configuration option.
The architectural differences between the two deployment options are:
• The OVO agent is not embedded on the NNM management station;

rather the OVO agent coexists with the NNM management station.
• The OVO server is used to start and configure the OVO agent on the
NNM management station to process syslog messages. As an OVO
administrator, you use the OVO configuration tools to upload the
syslog message source templates to the OVO agent and synchronize
the OVO message source templates with NNM trapd.conf.
• NNM forwards the SNMP traps to either (or both) the OVO message
browser or the NNM alarm browser, depending on how messages are
configured to be diverted through the system.
Figure 6-2 on page 154 shows the flow of events for the OVO with NNM
configuration. This illustration assumes that the router is configured to
forward syslog events to the NNM management station.
Chapter 6 153
Syslog Integration
Figure 6-2 Flow of Events for OVO with NNM Configuration
OVO message NNM alarm

browser browser
OVO Server ovtrap2opc
NNM Management
Station OV alarm
SNMP
Traps pmd
template
OVO Agent
OV SNMP event
syslogTrap
Syslog to
NNM
template Enabled
Template
and Agent
MSI
Logfile
syslogd logfile ASCII Encapsulator OVO-like message
router syslog message
To construct and modify the Syslog to NNM message source template,

use the standard OVO template editor. To launch the OVO template
editor, see “OVO Message Source Templates Window” on page 155.
Configuration Tools
This section describes the tools needed to configure the NNM Syslog
Integration functionality. The tools and steps required differ depending
on your deployment option.
154 Chapter 6
Syslog Integration
NNM Syslog Trap Mapping Configuration Interface

When you deploy the NNM standalone configuration option, you
construct and modify the Syslog Integration message source template
conditions through the Syslog Trap Mapping Configuration interface.
To launch the Syslog Trap Mapping Configuration interface, execute:
$OV_BIN/ovsyslogcfg
For instructions on how to use the Syslog Trap Mapping Configuration
interface, see the Syslog Trap Mapping Configuration Online Help.
OVO Message Source Templates Window

When you deploy the OVO with NNM configuration option, you construct
and modify Syslog Integration message source template conditions
through the Message Source Templates configuration window.
To open the Message Source Templates configuration window, launch
the OVO administrator interface ($OV_BIN/OpC/opc) and then click
Window:Message Source Templates.
For instructions on how to use the Message Source Templates
configuration window, see the OVO Administrator Online Help.
Syslog Configuration Command

The Syslog Integration functionality is not enabled when NNM is
installed. To enable and deploy a syslog configuration, use the command
line script, setupSyslog.ovpl.
Use the -help option to display a help message for the
setupSyslog.ovpl command options.
In the NNM Standalone Deployment Mode When the NNM

standalone configuration option is deployed, execute the syslog
configuration command with the -standalone option by typing:
setupSyslog.ovpl -standalone
This command does the following on your NNM management station:
• Deploys the out-of-the-box syslog template, Syslog to NNM.

• Activates the embedded OVO agent.
• Activates and registers the SNMP mapping background process,
syslogTrap.
Chapter 6 155
Syslog Integration
For detailed configuration steps, see “Configuring Syslog Integration for

NNM Standalone” on page 161.
The setupSyslog.ovpl configuration command is also used to deploy
new syslog configurations. After editing syslog message source template
conditions with the Syslog Trap Mapping Configuration interface,
execute setupSyslog.ovpl -standalone -deploy to deploy the new
configuration. The -deploy command option generates and encrypts the
new template and restarts the embedded OVO agent so that the new
template is reloaded.
In the OVO with NNM Deployment Mode When the OVO with
NNM configuration option is deployed, execute the syslog configuration
command with the -server option by typing: setupSyslog.ovpl
-server
This command creates an uploadable template configuration directory
for the out-of-the-box syslog template, Syslog to NNM.
After executing this command, you must perform the following
configuration steps:
• Upload the Syslog to NNM template into the OVO database.

• Start and register the NNM mapping process, syslogTrap.
• Enable the template MSI and the OVO agent MSI.
• Assign and install the Syslog to NNM template to the OVO agent
installed on the NNM management station.
For detailed configuration steps, see “Configuring Syslog Integration for
OVO with NNM on the Same System” on page 163.
Default Syslog Trap Mappings

NNM includes out-of-the-box template conditions for which syslog
messages are mapped to OpenView SNMP traps. Each type of syslog
message to be mapped is defined in one template condition. The
conditions are contained in the Syslog to NNM template.
The Syslog to NNM template includes out-of-the-box message condition
definitions to match the following types of messages:
• Link Down and Link Up messages

• Line Protocol messages
156 Chapter 6
Syslog Integration
• Frame relay messages

• HSRP messages
• OSPF messages
• Trunk (port aggregation) messages, including Port Aggregation
Protocol (PAGP) and Dynamic Trunking Protocol (DTP) messages
• Border Gateway Protocol (BGP) messages
• Spanning Tree Protocol (STP) message
• CDP messages
OpenView traps are defined to support the out-of-the-box syslog message
mappings. The list of mapped traps is described in Table 6-1.
Table 6-1 Syslog Trap Mappings
Syslog Message OpenView Event Generated
%LINK-3-UPDOWN (down) OV_Syslog_LinkDown
%LINK-3-UPDOWN (up) OV_Syslog_LinkUp
%LINEPROTO-5-UPDOWN (down) OV_Syslog_LineProtoDown
%LINEPROTO-5-UPDOWN (up) OV_Syslog_LineProtoUp
%FR-5-DLCICHANGE (INVALID) OV_Syslog_FrameDLCI_Invalid
%FR-5-DLCICHANGE (INACTIVE) OV_Syslog_FrameDLCI_Inactive
%FR-5-DLCICHANGE (ACTIVE) OV_Syslog_FrameDLCI_Active
%OSPF-5-ADJCHG (DOWN) OV_Syslog_OSPF_Neighbor_Down
%OSPF-5-ADJCHG (FULL) OV_Syslog_OSPF_Neighbor_Up
%STANDBY-6-STATECHANGE (Speak) OV_Syslog_HSRP_State_Speak
%STANDBY-6-STATECHANGE (Standby) OV_Syslog_HSRP_State_Standby
%STANDBY-6-STATECHANGE (Active) OV_Syslog_HSRP_State_Active
%STANDBY-6-STATECHANGE (Init) OV_Syslog_HSRP_State_Init
%STANDBY-3-DUPADDR OV_Syslog_HSRP_Duplicate_Address
%SNMP-5-MODULETRAP OV_Syslog_Card_Up OV_Syslog_Card_Down
Chapter 6 157
Syslog Integration
Table 6-1 Syslog Trap Mappings (Continued)
%SYS-5-MOD_NORESPONSE OV_Syslog_Card_Failure
%SYS-5-MOD_OK OV_Syslog_Card_Online
%SYS-5-MOD_REMOVE OV_Syslog_Card_Removed
%SYS-5-MOD_INSERT OV_Syslog_Card_Inserted
%SYS-5-MOD_RESET OV_Syslog_Card_Reset
%SYS-3-MOD_FAIL OV_Syslog_Card_Failure
%SYS-3-MOD_FAILREASON OV_Syslog_Card_Failure
%SYS-3-MOD_CFGMISMATCH1 OV_Syslog_Card_Config_Mismatch
%PAGP-5-PORTTOSPT OV_Syslog_PAGP_JoinedBridgePort
%PAGP-5-PORTFROMSPT OV_Syslog_PAGP_LeftBridgePort
%DTP-3-TRUNKPORTFAIL OV_Syslog_Trunk_Port_Fail
%DTP-3-NONTRUNKPORTFAIL OV_Syslog_Trunk_NonTrunkPort_Fail
%DTP-5-TRUNKPORTON OV_Syslog_Trunk_Port_On
%DTP-5-TRUNKPORTCHG OV_Syslog_Trunk_Port_Change
%OSPF (all other OSPF messages) OV_Syslog_OSPF_Default_Message
%STANDBY (all other HSRP messages) OV_Syslog_HSRP_Default_Message
%PAGP (all other PAGP messages) OV_Syslog_PAGP_Default_Message
%SYS-n-MOD (all other Cisco card OV_Syslog_Card_Default_Message

messages)
%DTP (all other %DTP trunk messages) OV_Syslog_Trunk_Default_Message
%SPANTREE OV_Syslog_Spantree_Default_Message
158 Chapter 6
Syslog Integration
Table 6-1 Syslog Trap Mappings (Continued)
%CDP OV_Syslog_CDP_Default_Message
%BGP OV_Syslog_BGP_Default_Message
Chapter 6 159
Syslog Integration
Configuring Syslog Integration

This chapter provides the steps necessary to setup the Syslog Integration
functionality in either the NNM standalone deployment mode or OVO
with NNM deployment mode.
Prerequisites for Configuring Syslog
DCE Software Requirements for Syslog
IMPORTANT Installation of DCE software is required only for NNM standalone

deployments.
IMPORTANT Installation of DCE software prerequisites are required only for HP-UX
11.0 operating systems. On HP-UX 11.11 or higher and Solaris operating
systems, the install process automatically installs HP's lightweight DCE,
if a supported DCE is not found.
Part of the syslog configuration process includes installing an HP

OpenView Operations (OVO) agent on the NNM management station.
The OVO agent requires two pieces of software to be installed prior to
configuring syslog: DCE RPC and DCE-KT-Tools. See the Release Notes
for more information about supported software versions.
The required DCE software is available on the HP-UX Application
Software CD-ROMs. To install the required DCE software, do the
following:
1. Invoke the SD Install interface by typing: swinstall

2. Change the software view by clicking: View:Change Software
View->Start with Products.
3. Install the first DCE software package by selecting
DCE-Core.DCE-CORE-RUN and clicking Actions:Install.
160 Chapter 6
Syslog Integration
4. Install the remaining DCE software package by selecting:

DCE-KT-Tools and clicking Actions:Install.
To check whether you have properly installed the required DCE
software, do the following:
1. Type: swlist | grep DCE

2. Look for two items in the list:
• DCE/9000 Programming and Administration Tools

• DCE/9000 Kernel Threads Support
Syslog Requirement in an NIS Environment
NOTE This step is required only for OVO with NNM configuration
deployments.
If the NNM management station being used for syslog monitoring is a

Network Information Service (NIS or NIS+) client, you need to install
the default OVO user, opc_op, and user group, opcgrp, on the NIS
server.
If the default OVO user, opc_op, and user group, opcgrp, are not
installed on the NIS server, or at least installed locally on the managed
node, you may get errors when installing agents and agent software on
the managed node.
To add opc_op locally on the managed node, edit the /etc/passwd file to
include an entry for opc_op. For example, the entry in the /etc/passwd
file could read:
opc_op:*:777:299:OpC default operator:/home/opc_op:/usr/bin/ksh
Configuring Syslog Integration for NNM Standalone
NOTE DCE software requirements must be installed before configuring the

Syslog Integration functionality. See “DCE Software Requirements for
Syslog” on page 160.
Chapter 6 161
Syslog Integration
The Syslog Integration functionality is not enabled when NNM

Advanced Edition is installed. To enable and deploy a syslog
configuration, use the command line script, setupSyslog.ovpl.
To enable Syslog Integration for NNM standalone configurations,
execute the following command on the NNM management server:
This command does the following on your NNM management station:
• Deploys the out-of-the-box syslog template, Syslog to NNM.

• Installs and activates the embedded OVO agent.
• Activates and registers the SNMP mapping process, syslogTrap.
To customize the out-of-the-box syslog template, see “Modifying the
Syslog to NNM Template” on page 162. For information about verifying
your syslog configuration, see “Testing Syslog Integration” on page 162.
Modifying the Syslog to NNM Template

For customizations to the Syslog to NNM template, use the Syslog Trap
Mapping Configuration interface. To launch the Syslog Trap Mapping
Configuration interface, execute:
$OV_BIN/ovsyslogcfg
interface, see the Syslog Trap Mapping Configuration Online Help and
“NNM Syslog Trap Mapping Configuration Interface” on page 174.
For more information about the Syslog to NNM template and its
conditions, see “Understanding the Syslog to NNM Template” on
page 177.
Testing Syslog Integration

Use the UNIX command line tool, logger, to write test messages to the
system logfile. Read its man page for more information on how to use the
command.
For example, to create a Line Protocol status Down syslog entry, do the
following:
HP-UX: logger %LINEPROTO-5-UPDOWN: Line protocol on
Interface interface2, changed state to down
162 Chapter 6
Syslog Integration
Solaris: logger -p user.err %LINEPROTO-5-UPDOWN: Line protocol

on Interface interface2, changed state to down
When Syslog Integration is enabled, you should see syslog messages
matching the conditions of the Syslog to NNM template forwarded to the
NNM alarm browser, as shown in Figure 6-3.
Figure 6-3 Syslog Messages in the NNM Status Alarms Browser
Configuring Syslog Integration for OVO with NNM on

the Same System
IMPORTANT If you are installing OVO on top of an NNM installation, be sure to

disable Syslog Integration functionality prior to installing OVO. For
instructions on disabling the Syslog Integration functionality, see
“Removing Syslog Integration” on page 171.

installed.
To enable and deploy a syslog configuration, do the following on the
NNM management station:
1. Execute: setupSyslog.ovpl -server
Chapter 6 163
Syslog Integration
This command creates an uploadable template configuration

directory for the out-of-the-box syslog template, Syslog to NNM,
under /var/opt/OV/share/tmp/NNMsyslogTraps. This command
also creates the syslog process, syslogTrap.
2. Register the syslogTrap process with NNM by executing the
following the commands:
a. Optional: Verify that the syslogTrap process is not already

registered. Open the $OV_CONF/ovsuf file and check to see if the
syslogTrap process is listed. If not, proceed with the
registration.
b. cd $OV_LRF
c. $OV_BIN/ovaddobj $OV_LRF/syslogTrap.lrf
d. Optional: To verify that the process is registered, open the
$OV_CONF/ovsuf file and check that syslogTrap is listed.
3. Upload the Syslog to NNM template into the OVO database by
typing:
opccfgupld NNMsyslogTraps
4. As user root, start HP OpenView Operations by typing:
$OV_BIN/OpC/opc
Since the NNM process, syslogTrap, relies on message stream
interface (MSI) to map syslog messages to SNMP traps, the MSI
must be enabled on the template and the OVO agent.
5. To enable the MSI on the Syslog to NNM template, do the following:
a. Open the Message Source Templates window by clicking Window:

Message Source Templates.
b. Select the Syslog to NNM template.
c. Click [Modify].
d. Click [Advanced Options].
e. Check Agent MSI and select Copy Messages.
f. Click [OK].
6. To enable the MSI on the OVO agent coexisting on the NNM
management station, do the following:
164 Chapter 6
Syslog Integration
a. From the Node Bank, select the node containing the OVO agent
coexisting on the NNM management station.
b. Click Actions:Node ->Modify.
c. From the Modify Node window, click [Advanced Options].
d. From the Node Advanced Options window, check Enable Output
from the Message Stream Interface pane.
e. Click [Close].
f. Click [OK] from the Modify Node window.
7. Assign the Syslog to NNM template to the OVO agent coexisting on
the NNM management station by doing the following:
b. Click Actions:Agents->Assign Templates. This opens the
Define Configuration window.
c. Click [Add]. The Add Configuration window displays.
d. Click [Open Template Window].
e. From the Message Source Templates window, select the Syslog
to NNM template.
f. From the Add Configuration window, click [Get Template
Selections].
g. Click [OK] in the Add Configuration window.
h. Click [OK] in the Define Configuration window.
8. Install the Syslog to NNM template on the OVO agent coexisting on
b. Click Actions:Agents->Install/Update SW & Config.
c. In the Install/Update ITO Software and Configuration window,
make sure the correct managed node is listed in the Target
Nodes pane.
d. Check Templates in the Components pane.
Chapter 6 165
Syslog Integration
e. Click [OK] to cause the template to be deployed on the managed

node. Afterwards, you should see a message in the OVO message
browser indicating that the agent system has been updated.
9. Start the NNM mapper process, syslogTrap, by executing:
$OV_BIN/ovstart syslogTrap
10. Pull in the latest SNMP trap definitions by doing the following:
• Execute: $OV_BIN/OpC/util/ovtrap2opc
See the ovtrap2opc man page for information about this
command.
• Check y when prompted to upload to SNMP Traps template.
• Install the SNMP Traps template on the OVO agent coexisting on
the NNM management station. For instructions on how to install
templates on a managed node, see step 7 on page 165.
11. Optional: Test your syslog configuration by sending sample syslog
messages through the system. For instructions, see “Testing Syslog
Integration” on page 166.
Syslog Logfiles
On HP-UX operating systems, the location of the system logfile,
syslog.log, that the Syslog to NNM template monitors is set to
/var/adm/syslog.
On Solaris operating systems, the location of the system logfile,
/var/adm/messages.

Use the UNIX command line tool, logger, to write messages to the
command.
following:
166 Chapter 6
Syslog Integration

NNM alarm browser or the OVO message browser, depending on your
configuration.
NOTE If you do not see syslog messages displayed in the NNM alarm browser,
follow the troubleshooting tips outlined in “Not Seeing Syslog Messages
in Message Browser” on page 193.
NOTE SNMP trap definitions can be modified for testing purposes. After
changing SNMP trap definitions, execute the ovtrap2opc command. For
instructions, see step 10 on page 166.
Configuring Syslog Integration for OVO with NNM on

Separate Systems
IMPORTANT If you are installing OVO on top of an NNM installation, be sure to

disable Syslog Integration functionality prior to installing OVO. For
instructions on disabling the Syslog Integration functionality, see
“Removing Syslog Integration” on page 171.

installed.
To enable and deploy a syslog configuration, do the following on the
NNM management station:
1. From the OVO server, execute:

setupSyslog.ovpl -server
This command creates an uploadable template configuration
directory for the out-of-the-box syslog template, Syslog to NNM,
under /var/opt/OV/share/tmp/NNMsyslogTraps. This command
also creates the syslog process, syslogTrap.
Chapter 6 167
Syslog Integration
2. From the OVO server, upload the Syslog to NNM template into the
OVO database by typing:
opccfgupld NNMsyslogTraps
3. From the OVO server, execute:
setupSyslog.ovpl -server -disable
4. From the remote NNM management station, execute:
setupSyslog.ovpl -server
5. From the remote NNM management station, register the
syslogTrap process with NNM by executing the following the
commands:
a. Optional: Verify that the syslogTrap process is not already

registered. Open the $OV_CONF/ovsuf file and check to see if the
syslogTrap process is listed. If not, proceed with the
registration.
b. cd $OV_LRF
c. $OV_BIN/ovaddobj $OV_LRF/syslogTrap.lrf
d. Optional: To verify that the process is registered, open the
$OV_CONF/ovsuf file and check that syslogTrap is listed.
6. From the OVO server as user root, start HP OpenView Operations
by typing: $OV_BIN/OpC/opc
Since the NNM process, syslogTrap, relies on message stream
interface (MSI) to map syslog messages to SNMP traps, the MSI
must be enabled on the template and the OVO agent.
7. To enable the MSI on the Syslog to NNM template, do the following:
a. Open the Message Source Templates window by clicking Window:

Message Source Templates.
b. Select the Syslog to NNM template.
c. Click [Modify].
d. Click [Advanced Options].
e. Check Agent MSI and select Copy Messages.
f. Click [OK].
168 Chapter 6
Syslog Integration
8. To enable the MSI on the OVO agent coexisting on the NNM

management station, do the following:
b. Click Actions:Node ->Modify.
c. From the Modify Node window, click [Advanced Options].
d. From the Node Advanced Options window, check Enable Output
from the Message Stream Interface pane.
e. Click [Close].
f. Click [OK] from the Modify Node window.
9. Assign the Syslog to NNM template to the OVO agent coexisting on
b. Click Actions:Agents->Assign Templates. This opens the
Define Configuration window.
c. Click [Add]. The Add Configuration window displays.
d. Click [Open Template Window].
e. From the Message Source Templates window, select the Syslog
to NNM template.
f. From the Add Configuration window, click [Get Template
Selections].
g. Click [OK] in the Add Configuration window.
h. Click [OK] in the Define Configuration window.
10. Install the Syslog to NNM template on the OVO agent coexisting on
b. Click Actions:Agents->Install/Update SW & Config.
c. In the Install/Update ITO Software and Configuration window,
make sure the correct managed node is listed in the Target
Nodes pane.
Chapter 6 169
Syslog Integration
d. Check Templates in the Components pane.

e. Click [OK] to cause the template to be deployed on the managed
node. Afterwards, you should see a message in the OVO message
browser indicating that the agent system has been updated.
11. Start the NNM mapper process, syslogTrap, by executing:
$OV_BIN/ovstart syslogTrap
12. Pull in the latest SNMP trap definitions by doing the following:
• Execute: $OV_BIN/OpC/util/ovtrap2opc
See the ovtrap2opc man page for information about this
command.
• Check y when prompted to upload to SNMP Traps template.
• Install the SNMP Traps template on the OVO agent coexisting on
the NNM management station. For instructions on how to install
templates on a managed node, see step 9 on page 169.
13. Optional: Test your syslog configuration by sending sample syslog
messages through the system. For instructions, see “Testing Syslog
Integration” on page 170.
Syslog Logfiles
On HP-UX operating systems, the location of the system logfile,
/var/adm/syslog.
On Solaris operating systems, the location of the system logfile,
/var/adm/messages.

Use the UNIX command line tool, logger, to write messages to the
command.
following:
170 Chapter 6
Syslog Integration

NNM alarm browser or the OVO message browser, depending on your
configuration.
NOTE If you do not see syslog messages displayed in the NNM alarm browser,
follow the troubleshooting tips outlined in “Not Seeing Syslog Messages
in Message Browser” on page 193.
NOTE SNMP trap definitions can be modified for testing purposes. After
changing SNMP trap definitions, execute the ovtrap2opc command. For
instructions, see step 12.
Removing Syslog Integration

Removing Network Node Manager from the system does not completely
remove Syslog Integration. The OVO agent is left enabled and running
on the system.
To remove the remaining Syslog Integration components, do the
following:
1. Disable the Syslog Integration feature by executing the following

command:
For NNM standalone configurations, type:
setupSyslog.ovpl -standalone -disable
For OVO with NNM configurations, type:
2. For NNM standalone configurations, remove the OVO agent
software from the NNM management station by doing the following:
a. Type: swremove (HP-UX) or pkgrm (Solaris)

This opens the SD Remove window.
Chapter 6 171
Syslog Integration
b. Select the ITOAgent software package name from the Name list.
c. Click Actions:Remove to remove the OVO agent from the NNM
management station.
172 Chapter 6
Syslog Integration
Customizing Message Source Templates

This section provides the steps necessary to create, modify, and enable
Syslog Integration message source templates. The configuration tools
used to modify message source templates are also described.
Overview of Message Source Templates

OVO agents are configured via message source templates. The OVO
agent can only format and forward a message that is described in a
message source template.
In the NNM standalone configuration, the OVO agent is embedded on
the NNM management station. In the OVO with NNM configuration, the
OVO agent coexists on the NNM management station. In either case, the
OVO agent is configured to monitor the status of and collect information
from syslog messages through the Syslog to NNM message source
template.
Message source templates work by identifying strings within messages
in message streams. When messages match the conditions defined in the
message source templates, they are processed according to the rules
defined in the template. When the Syslog Integration functionality is
enabled, messages matching markers defined in the Syslog to NNM
template are forwarded to the NNM syslogTrap process. This process
maps the syslog messages to SNMP traps.
Message source templates consist of the following elements:
• Type of message source from which you want to collect messages,

such as a logfile, a trap, an OVO message interface, or an action. In
the case of the Syslog to NNM template, the message source is a
logfile.
• Message conditions and suppress conditions that match a set of
attributes and define responses to received messages. These
conditions filter incoming messages from the message source. The
conditions also determine how the “important” messages are
displayed in the operator window.
• Options, such as default message logging.
Chapter 6 173
Syslog Integration
Understanding the Template Configuration Tools

There are two main template editing tools used to create and modify
syslog configuration template conditions. For NNM standalone
configurations, use the Syslog Trap Mapping Configuration interface
(see “NNM Syslog Trap Mapping Configuration Interface” on page 174).
For OVO with NNM configurations, use the OVO Message Source
Templates window (see “OVO Message Source Templates Window” on
page 176). Details on how to use these template editing tools can be
found in their respective online help volumes.
NNM Syslog Trap Mapping Configuration Interface

When the NNM standalone configuration option is deployed, you
construct and modify Syslog Integration message source template
conditions through the Syslog Trap Mapping Configuration interface.
To launch the Syslog Trap Mapping Configuration interface, execute:
$OV_BIN/ovsyslogcfg
The main dialog for the Syslog Trap Mapping Configuration interface is
shown in Figure 6-4 on page 175. This dialog supports the following
actions:
• Add or delete template conditions.

• Modify template conditions.
• Enable and disable template conditions.
• Reorder template conditions.
For this release, ten syslog template conditions are defined. These
conditions are explained in greater detail in “Understanding the Syslog
to NNM Template” on page 177.
interface, see the Syslog Trap Mapping Configuration Online Help.
174 Chapter 6
Syslog Integration
Figure 6-4 Syslog Trap Mapping Configuration Dialog
Chapter 6 175
Syslog Integration
OVO Message Source Templates Window

When the OVO with NNM configuration option is deployed, you
construct and modify Syslog Integration message source template
conditions through the Message Source Templates configuration
window.
To open the Message Source Templates configuration window, launch
HP OpenView Operations ($OV_BIN/OpC/opc) as an Administrator and
then click Window:Message Source Templates.
The Message Source Templates window is shown in Figure 6-5 on
page 176. The Syslog to NNM template for HP-UX operating systems
and Syslog to NNM (Solaris) template for Solaris operating systems
contain the conditions that map syslog message to OpenView SNMP
traps.
Figure 6-5 OVO Message Source Templates Window
With the NNM to Syslog template for your operating system selected,
you can use this dialog to perform the following actions:
176 Chapter 6
Syslog Integration
• Modify the properties of the template by clicking [Modify].

• Modify the template conditions by clicking [Conditions].
For instructions on how to use the Message Source Templates window,
see the OVO Administrator Online Help.
Understanding the Syslog to NNM Template

NNM includes out-of-the-box template conditions for which syslog
messages are mapped to OpenView SNMP traps. Each type of syslog
message to be mapped is defined in one template condition. The
conditions are contained in the Syslog to NNM template.
The Syslog to NNM template contains many out-of-the-box conditions.
Figure 6-6 shows the template conditions as they appear in the OVO
Message and Suppress Conditions window.
Chapter 6 177
Syslog Integration
Figure 6-6 Syslog to NNM Template Conditions
178 Chapter 6
Syslog Integration
In both the OVO template editor windows and the NNM Syslog Trap
Mapping Configuration interface, the order of the conditions is important
for pattern matching. The patterns are tested in the order that they are
listed, and the first pattern to match is executed.
NOTE Since ordering of template conditions matters, it is important to place

suppression patterns first and more specific patterns at the beginning of
the list. More general patterns should go last.
The first condition is a suppress unmatched condition, meaning the

pattern will exclude any message that does not conform to its pattern. In
this case, the pattern matches only those syslog messages with the %
character as the leading non-white space character in the message
(specifically, Cisco syslog message types). This pattern does not
functionally perform anything, but is significant as an optimization tool,
since all other conditions in this template will execute only on Cisco
syslog messages.
The remaining conditions look for Cisco syslog messages matching
defined patterns as identified in Table 6-2.
Table 6-2 Template Conditions and Corresponding Syslog Messages
Template Condition Name Syslog Message Format
Syslog LINEPROTO down %LINEPROTO-5-UPDOWN (down)
Syslog LINEPROTO up %LINEPROTO-5-UPDOWN (up)
Syslog FRAME DLCI Invalid %FR-5-DLCICHANGE (INVALID)
Syslog FRAME DLCI Inactive %FR-5-DLCICHANGE (INACTIVE)
Syslog FRAME DLCI Active %FR-5-DLCICHANGE (ACTIVE)
Syslog OSPF Adjacency up %OSPF-5-ADJCHG (FULL)
Syslog OSPF Adjacency down %OSPF-5-ADJCHG (DOWN)
Syslog LINKUP %LINK-3-UPDOWN (up)
Syslog LINKDOWN %LINK-3-UPDOWN (down)
Syslog HSRP state speak %STANDBY-6-STATECHANGE (Speak)
Chapter 6 179
Syslog Integration
Syslog HSRP state standby %STANDBY-6-STATECHANGE (Standby)
Syslog HSRP state active %STANDBY-6-STATECHANGE (Active)
Syslog HSRP state init %STANDBY-6-STATECHANGE (Init)
Syslog HSRP duplicate address %STANDBY-3-DUPADDR
Syslog Cisco Card Up(Down) Trap %SNMP-5-MODULETRAP
Syslog Cisco Card Failure %SYS-5-MOD_NORESPONSE

%SYS-3-MOD_FAIL
%SYS-3-MOD_FAILREASON
Syslog Cisco Card Online %SYS-5-MOD_OK
Syslog Cisco Card Removed %SYS-5-MOD_REMOVE
Syslog Cisco Card Inserted %SYS-5-MOD_INSERT
Syslog Cisco Card Reset %SYS-5-MOD_RESET
Syslog Cisco Card Configuration Mismatch %SYS-3-MOD_CFGMISMATCH[1,2,3,4]
Syslog PAGP Joined Bridge Port %PAGP-5-PORTTOSPT
Syslog PAGP Left Bridge Port %PAGP-5-PORTFROMSPT
Syslog Trunk Port Failed %DTP-3-TRUNKPORTFAIL
Syslog Non-Trunk Port Failed %DTP-3-NONTRUNKPORTFAIL
Syslog Trunk Port On %DTP-5-TRUNKPORTON
Syslog Trunk Port Change %DTP-5-TRUNKPORTCHG
Syslog OSPF other message %OSPF
Syslog HSRP other message %STANDBY
Syslog PAGP other %PAGP
Syslog Cisco Card Message %SYS-n-MOD
180 Chapter 6
Syslog Integration
Syslog Trunk other %DTP
Syslog STP other %SPANTREE
Syslog CDP %CDP
Syslog BGP other message %BGP
How Syslog to NNM Conditions Function in the NNM

Standalone Configuration
Figure 6-7 shows a condition window to modify a Syslog to NNM
template condition definition. The window is divided into two logical
parts: a condition text field to match patterns and a set of attributes that
define the SNMP trap to be generated.
The Condition Text field uses syntax similar to a regular expression. It
identifies the pattern to match and names any subexpressions in the
pattern to be used in the mapping to an SNMP trap. See the NNM Syslog
Trap Mapping Configuration Online Help for more information about
pattern matching.
Chapter 6 181
Syslog Integration
Figure 6-7 Modify Message Condition Window for Syslog LINKDOWN
The Position field identifies the location of the condition with respect to
the other conditions of the template.
The Trap OID is defined by the enterprise, generic, and specific fields.
The trap OID is used to determine the type of OpenView event to be
generated in response to a message matching the condition pattern.
The varbinds of the trap are defined in the lower table, as shown in
Figure 6-7.
You can edit the Condition Text and the Trap OID fields. You can also
modify and reorder any of the varbinds. See the NNM Syslog Trap
Mapping Configuration Online Help for more information about
modifying these fields.
Messages matching the pattern defined in the Condition Text field
cause the OpenView event identified by the Trap OID to be generated.
For example, when a %LINK-3-UPDOWN status DOWN message is logged to
the syslog file, the message is intercepted, since the Syslog LINKDOWN
182 Chapter 6
Syslog Integration
condition looks for this pattern (as shown in the Condition Text field of
Figure 6-7). In that same condition, a trap OID is identified, which
corresponds to the OpenView event, OV_Syslog_LinkDown, as shown in
Figure 6-8 on page 184. This event is then generated.
To view or identify the corresponding OpenView event to be generated,
do the following:
1. Start the NNM GUI by typing: ovw

2. From the Root window, click Options: Event Configuration.
3. Select OpenView from the Enterprise Name list. A list of OpenView
events displays in the bottom pane.
4. Locate the trap OID from the Event Identifier list.
5. Double-click the event or click Edit:Modify Event to display the
Event Configurator/Modify Event window. An example is shown in
Figure 6-8 on page 184.
Chapter 6 183
Syslog Integration
Figure 6-8 OV_Syslog _LinkDown Event Configuration Window
How Syslog to NNM Templates Function in the OVO

with NNM Configuration
Figure 6-9 on page 185 shows a condition window to modify a Syslog to
NNM template condition definition. The window is divided into three
logical parts: input section, condition matching section, and message
output section.
184 Chapter 6
Syslog Integration
Figure 6-9 OVO Condition Editing Window
The top part contains the input section. Messages are matched according
to values stored in the fields listed in Table 6-3.
Table 6-3 Input Fields for OVO Template Conditions
Field Description Size
Node Course-grained identifier for the source 254

of a message, such as software.hp.com.
Chapter 6 185
Syslog Integration
Table 6-3 Input Fields for OVO Template Conditions (Continued)
Message Text Content and/or description of a message. 512

Use OVO’s regular expression-like
syntax to define the Message Text.
Right-click in the field to view a short
list of acceptable regular expressions.
For example, if you want to match
messages on the string “Switch1”, then
define the Message Text field to be
<*>Switch1<*>.
See the OVO Administrator Online Help
for more information on writing pattern
matching expressions.
The matching conditions section describes how the conditions are to be

treated. The options are listed in Table 6-4.
Table 6-4 Matching Conditions for OVO Template
Conditions
Option Description
Suppress Matched Condition Suppresses all messages

matching condition fields in the
input section. Messages are
stored in a log file, rather than
displaying in the OVO message
browser.
Identified by the – symbol.
Suppress Unmatched Condition Suppresses all messages not

matching condition fields in the
input section. Messages are
stored in a log file, rather than
displaying in the OVO message
browser.
Identified by the = symbol.
186 Chapter 6
Syslog Integration
Table 6-4 Matching Conditions for OVO Template

Conditions (Continued)
Option Description
Message on Matched Condition Forwards all messages matching

condition fields in the input
section to the OVO message
browser.
Identified by the + symbol.
The lower portion contains the output section. The fields in this section
correspond to columns in the message browser. Use these fields to
reformat the original message into a more readable format for end users.
When any of these fields are unspecified, values are copied from the
original message. Table 6-5 lists the key message fields, their intended
usage, and their size limitations.
NOTE If the value of an output field is a named subexpression from the

Message Text input field, it must be enclosed in angle brackets (<>).
Table 6-5 Output Fields of OVO Template Conditions
Node Identifies the source of a message. In 254

the Syslog to NNM template
conditions, the value of this field is
pulled from the incoming syslog
message. Its value is stored in the
variable node.
Application Medium-grained identifier for a 32

message source. For example, Oracle.
Message Group Group of alarms to which a message 32

belongs.
Object Fine-grained message source 32

identifier. For example, Syslog.
Chapter 6 187
Syslog Integration
Table 6-5 Output Fields of OVO Template Conditions (Continued)
Message Text Contains the description text of a 2048

message.
Service Name Identifier used to associate a message 254

with a service.
Message Type Identifier of a subgroup of a message 32

group. In order for syslog messages to
be forwarded to the NNM
syslogTrap process, NNMsyslog_ is
required to be entered in this field.
NOTE Be aware that Node, Application, Message Group, and Object fields are
used by administrators to create filtered views in the OVO interface.
Consistent use of these fields is paramount to enabling operators to
effectively monitor equipment for which they are responsible.
From the OVO condition editing window, as shown in Figure 6-9 on

page 185, you add, delete, or modify custom message attributes (CMAs).
Custom message attributes allow you to add your own attributes to a
message. This means that in addition to the default message attributes,
you can extend OVO with attributes of your choice.
To assign custom message attributes to a message, use the Custom
Message Attributes window. To open, click [Custom Attributes] from
the OVO condition editing window. For example, Figure 6-10 shows a list
of defined custom message attributes for the syslog LINKDOWN
condition.
The Name field defines the name of the attribute that is displayed as an
additional column in the message browser. The Value field sets the value
of the attribute. A Value entry can contain either hard-coded text or a
variable defined in the Message Text input field.
188 Chapter 6
Syslog Integration
Figure 6-10 OVO Custom Message Attributes
If you have enabled the display of custom message attributes in your

OVO message browser, they appear as additional columns in your OVO
message browser.
Chapter 6 189
Syslog Integration
Maintaining Syslog Integration

This section provides instructions for tasks that an NNM administrator
would need to perform to maintain the working of the Syslog Integration
functionality.
Administrative Tasks for NNM Standalone

Configurations
Deploying Syslog to NNM Template

After editing syslog message source template conditions with the Syslog
Trap Mapping Configuration interface, execute
setupSyslog.ovpl -standalone -deploy
to deploy the new configuration.
The -deploy command option generates and encrypts the new template
and restarts the embedded OVO agent so that the new template is
reloaded.
Testing Patterns in Template Conditions

Before you redeploy the Syslog to NNM template, you can verify the
syntax of any template condition by executing:
opcpat
Read the man page for opcpat for instructions on how to use the
command.
Disabling Syslog Integration Functionality

To disable the syslog functionality, execute:
setupSyslog.ovpl -standalone -disable
This command stops the embedded OVO agent processes and the NNM
syslogTrap process. The OVO agent software remains on the NNM
management station. To remove the OVO agent software, see “Removing
Syslog Integration” on page 171.
You can re-enable the Syslog Integration functionality, by executing:
190 Chapter 6
Syslog Integration
Administrative Tasks for OVO with NNM

Configurations
Disabling Syslog Integration Functionality

To disable the Syslog Integration functionality, execute:
Starting and Stopping syslogTrap

To start the NNM syslogTrap process, execute:
ovstart -c syslogTrap
NOTE This process is not registered with NNM until you execute the
setupSyslog.ovpl configuration script. Therefore, you cannot start this
process until you have run the setupSyslog.ovpl script.
To stop the syslogTrap process, execute:

ovstop -c syslogTrap
Chapter 6 191
Syslog Integration
Troubleshooting Tips
Here are some troubleshooting tips for the Syslog Integration
functionality.
System Logfiles
On HP-UX operating systems, syslog entries are logged to
/var/adm/syslog/syslog.log.
On Solaris operating systems, syslog entries are logged to
/var/adm/messages/syslog.log.
Performance
The Syslog Integration functionality is not intended for high volume
syslog message systems.
Some performance issues may arise as the syslog messages from the
managed network elements can become extremely abundant. Sufficient
tuning of the Syslog to NNM template conditions may need to be done
for exclusion patterns to improve performance. Additionally, you may
need to add some filtering mechanism to the NNM background process
(syslogTrap) that maps the syslog message to an SNMP trap.
Configuration
Seeing Duplicate Syslog Messages in Message Browser:
This could be caused by a number of reasons, including one of the
following:
• In OVO with NNM configurations, you must enable the message

stream interface for both the Syslog to NNM template and the OVO
agent on the NNM management station in order for syslog messages
to be processed as documented. However, in OVO, there are a
multitude of combinations for diverting messages through the
system. For example, you can enable the message stream interface
for individual conditions of a template to copy messages as well as
enabling the message stream interface for the template to copy
messages. This will produce multiple messages in the message
browser.
192 Chapter 6
Syslog Integration
• Templates are not ordered, meaning that if messages match

conditions of multiple templates, multiple messages are displayed in
the message browser. For example, if a wildcard template is assigned
and installed on a system, then every message entering the agent is
forwarded to the message browser. Furthermore, if additional
templates are assigned and installed on a system, then those
messages matching the conditions of the templates are also
forwarded to the message browser. Thus, duplicate messages appear
in the message browser, formatted according to rules in the
templates.
Not Seeing Syslog Messages in Message Browser
This could be caused by many reasons, including one of the following:
• The Syslog to NNM template is not installed or enabled on the OVO

agent system (on the NNM management station). To verify that the
Syslog to NNM template is installed and enabled on the OVO agent,
execute:
$OV_BIN/OpC/opctemplate
This command lists all templates with the type, name, and status
(enabled or disabled). This command is helpful to check whether a
template you have assigned to an agent node has successfully been
installed on that agent system.
Be aware that this command does not indicate which version of the
template has been deployed. If you have made modifications to any
assigned templates, you must reinstall the templates on the
managed nodes.
• For OVO with NNM configurations, the message stream interface is
not enabled for either the Syslog to NNM template or the OVO agent
on the NNM management station.
To isolate the problem, you can turn on XPL tracing for the
syslogTrap process. If you see no activity in incoming messages, it
usually means that the message stream interface has not been
enabled in all places that must be enabled.
• The templates are marked as log only. Use the NNM Event
Configuration window to change the logging state. From any NNM
submap, select Options:Event Configuration.
• When APA is enabled, several correlators are added to HP OpenView
Correlation Composer that listen for and correlate syslog messages.
You may not see some syslog messages in the alarm browser because
Chapter 6 193
Syslog Integration
the APA-enabled correlators may discard the syslog messages or nest

them under APA status alarms. For a description of the APA
correlators and how syslog messages take part in event reduction,
see Chapter 7, “APA and Event Reduction,” on page 195.
194 Chapter 6
7 APA and Event Reduction
Chapter 7 195
APA and Event Reduction
NNM’s Event Reduction Capabilities When APA Is Enabled
NNM’s Event Reduction Capabilities When

APA Is Enabled
NM includes a set of built-in correlators that are enabled out-the-box.
These basic correlators are described in detail in the Event Reduction
chapter of Managing Your Network.
This chapter explains additional NNM correlators that are enabled when
APA is configured.
Correlation Composer and APA Correlators

The APA correlators are defined using HP OpenView Correlation
Composer.
NOTE The instructions and information provided within this chapter are
described using the operator mode of the HP OpenView Correlation
Composer user interface. For more information about HP OpenView
Correlation Composer, see HP OpenView Correlation Composer’s Guide.
Syslog Integration and APA Correlators

Syslog Integration and APA are distinct pieces of functionality provided
with NNM Advanced Edition. Each can be enabled individually;
however, the most benefit is achieved when Syslog Integration is enabled
in conjunction with APA functionality.
Many of the correlators provided with APA work on syslog events. For
example, certain syslog messages causes an immediate APA poll of the
network device identified in the message. Other correlators listen for
syslog messages and nest them beneath the appropriate APA alarm,
enabling better root cause analysis.
For more information about the Syslog Integration functionality, see
Chapter 7, “APA and Event Reduction,” on page 195.
196 Chapter 7
NNM’s Event Reduction Capabilities When APA Is Enabled
NOTE If Syslog Integration functionality is not enabled but APA is enabled,

then some of the APA correlators may not be of use. To disable the syslog
correlators, see “Disabling APA Correlators and Correlator Groups” on
page 232.
Chapter 7 197
Overview of APA Correlators

The APA-enabled correlators are logically divided into seven
namespaces: OV_PollerIntermittent, OV_PollerLinkDown,
OV_CiscoBoard, OV_PollerBoardDown, OV_PollerTrigger,
OV_PollerTriggerCorr, and OV_PollerPortAgg.
NOTE The term board is used within this chapter as the HP generic term and
is interchangeable with other vendor terms, including card and
module. For information on the board and port information that NNM
Extended Topology can discover, see “Discovering Board and Port
Information on Cisco Devices” on page 21.
NOTE The term aggregated port is used within this chapter as the generic
HP term and is interchangeable with the term trunk.
The OV_PollerIntermittent namespace contains a set of correlators

that notify you when a network component is flapping. When APA status
change alarms or LinkDown/LinkUp transitions exceed a count
threshold during a specified time interval, flapping events are generated.
One flapping alarm is generated for each type of object (link, node,
interface, address, or connection).
• “Multiple LinkDown Traps” on page 203

Listens for LinkDown events and creates a new alarm
(OV_Link_Intermittent) when more than N LinkDown events are
received within M minutes from the same source (defaults N=3,
M=30 minutes).
• “Node Intermittent Status Change” on page 204
Listens for OV_APA_NODE_DOWN alarms from the APA poller and
creates a new node intermittent status alarm
(OV_APA_NODE_Intermittent) when N APA node-down events are
received from the same source within M minutes (defaults N=2,
M=30 minutes).
198 Chapter 7
• “Interface Intermittent Status Change” on page 205

Listens for OV_APA_IF_DOWN alarms from the APA poller and creates
a new interface intermittent status alarm
(OV_APA_IF_Intermittent) when N APA interface-down events are
received within M minutes from the same source (defaults N=2,
M=30 minutes).
• “Address Intermittent Status Changes” on page 206
Listens for OV_APA_ADDR_DOWN alarms from the APA poller and
creates a new address intermittent status alarm
(OV_APA_ADDR_Intermittent) when N APA address-down events
are received within M minutes from the same source (defaults N=2,
M=30 minutes).
• “Connection Intermittent Status Change” on page 207
Listens for OV_APA_CONNECTION_DOWN alarms from the APA poller
and creates a new connection intermittent status alarm
(OV_APA_CONN_Intermittent) when N APA connection-down events
are received within M minutes from the same source (defaults N=2,
M=30 minutes).
The OV_PollerLinkDown namespace contains a set of correlators that
determine if the root cause of a LinkDown event is a result of a node or
connection going down. When appropriate, the LinkDown events are
correlated under the APA root cause alarm and then removed from the
alarm browser.
• “LinkDown Events and APA Node Status Alarms” on page 209

(a combination of two correlators) Correlates LinkDown events with
APA node-down alarms, OV_APA_NODE_DOWN. LinkDown events
received within M minutes from the same source as the APA node
status alarm are suppressed and nested beneath the APA node
status alarm (default M=10 minutes).
• “LinkDown Events and APA Connection Status Alarms” on page 210
(a combination of two correlators) Correlates LinkDown events with
APA connection-down alarms, OV_APA_CONNECTION_DOWN or
OV_APA_CONNECTION_UNREACHABLE. LinkDown events received
within M minutes from the same source as the APA connection
status alarm are suppressed and nested beneath the APA connection
status alarm (default M=10 minutes).
Chapter 7 199
The OV_CiscoBoard namespace contains a set of correlators that

determine if LinkDown events and syslog Link Down and Line Protocol
Down messages are secondary events to Board Down (or ModuleDown)
events. Secondary events are correlated under the root cause event
identifying the board (or module) that failed.
• “LinkDown and Syslog Down Events with Board Down Events” on

page 212
(a combination of four correlators) Listens for LinkDown events,
syslog Link Down messages, and syslog Line Protocol Down
messages as well as Board Down (or ModuleDown) events. The
correlators store the events based on the board (or module) ID and
the node ID extracted from the topology database.
These correlators nest secondary events, including LinkDown events
and syslog Down events, beneath the Board Down event.
• “LinkDown and Syslog Down Events with Syslog Board Down
Events” on page 213
(a combination of four correlators) Listens for LinkDown events,
syslog Link Down messages, and syslog Line Protocol Down events
as well as syslog Board Down (or ModuleDown) events. The
correlators store the events based on the board (or module) ID and
the node ID extracted from the topology database.
These correlators nest secondary events, such as LinkDown events
and syslog Down events, beneath the syslog Board Down event.
• “Board Down and Syslog Board Down Events Correlator” on
page 214
The OV_Board_Trap_SyslogCorr correlator correlates Board Down
events and syslog Board Down messages. The first event to arrive is
displayed in the alarm browser. Subsequent events are nested under
the first event. The correlator matches events based on the board (or
module) ID.
The OV_PollerBoardDown namespace contains a set of correlators that
determine if Board Down events or syslog Board Down messages should
be nested under the root cause APA Board Down alarm. When
appropriate, the Board Down events are correlated under the APA Board
Down alarm and then removed from the alarm browser.
• “Board Down Events with APA Board Failure Alarms” on page 216
200 Chapter 7
(a combination of two correlators) Correlates Board Down

(ModuleDown) events with APA Board Down alarms. The correlators
match alarms based on the board (or module) ID and the node ID
extracted from the topology database.
• “Syslog Board Down Events with APA Board Failure Alarms” on
page 217
(a combination of two correlators) Correlates syslog Board Down
messages with APA Board Down alarms. The correlators match
alarms based on the board (or module) ID and the node ID extracted
from the topology database.
The OV_PollerTrigger namespace contain a set of correlators that
trigger an immediate APA poll and analysis of a network entity (of type
node, interface, board, or HSRP group). When certain types of traps or
syslog messages arrive, these correlators generate the appropriate APA
poll trigger request on the network entity. Depending on the type of
event, the correlators may issue a status poll request, a configuration
poll request, or a force poll request.
• “APA Poll Trigger Requests” on page 219

(a set of fourteen correlators) Generates an APA Demand Analysis
alarm that triggers an immediate APA poll on the network entity
specified in the event. When no other events of the same event source
and poll type have been sent to the APA poller within a specified
time period, the network entity is immediately polled.
The OV_PollerTriggerCorr namespace contains a set of correlators
that correlate duplicate poll trigger events not already being correlated
by the other APA correlators. Secondary events are correlated under the
first event to arrive or under the APA alarm that is generated as a result
of the poll request.
• “OSPF Adjacency Change Events with APA Root Cause Alarms” on

page 224
(a set of two correlators) Correlates OSPF Adjacency Change events
with the appropriate APA root cause alarm, OV_APA Connection or IF
status alarms. OSPF Adjacency Change events received within a
specified time period from the same source as the APA root cause
alarm are suppressed and nested beneath the APA root cause alarm.
• “HSRP State Change Events with HSRP Root Cause Alarms” on
page 225
Chapter 7 201
(a set of two correlators) Correlates HSRP State Change events with

the appropriate APA root cause alarm, OV_HSRP_*. HSRP State
Change events received within a specified time period from the same
source as the APA root cause alarm are suppressed and nested
beneath the APA root cause alarm.
• “Restart-Type Events with APA Node Status Alarms” on page 225
(a set of three correlators) Correlates Cold Start and Warm Start
events as well as syslog RELOAD and RESTART messages with APA
node status alarms, OV_APA_NODE_UP. Events received within a
specified time period from the same source as the APA node status
alarm are suppressed and nested beneath the APA node status
alarm.
The OV_PollerPortAgg namespace contains a set of correlators that
determine if LinkDown events and syslog Down events as well as syslog
port aggregation events are secondary events to APA port aggregation
status alarms. Secondary events are correlated under the APA root cause
alarm.
• “LinkDown Events and Syslog Down Events with APA Aggregated

Port Alarms” on page 227
(a set of two correlators) Listens for LinkDown, syslog Link Down,
and syslog Line Protocol Down events as well as APA Aggregated
Port alarms. The correlators store the events based on the node ID
extracted from the topology database. LinkDown events and syslog
Down events received within a specified time period matching the
node ID of the APA Aggregated Port alarm are suppressed and
nested beneath the APA Aggregated Port alarm.
• “Syslog Port Aggregation Events with APA Aggregated Port Alarms”
on page 228
(a set of two correlators) Listens for APA Aggregated Port alarms and
syslog port aggregation (PAGP) events, which provide notification of
when a physical port has joined or left an aggregated port. The
correlator stores the syslog port aggregation events based on the
node ID extracted from the topology database. Syslog port
aggregation events received within a specified time period matching
the node ID of the APA Aggregated Port alarm are suppressed and
nested beneath the APA Aggregated Port alarm.
202 Chapter 7
OV_PollerIntermittent Namespace
The OV_PollerIntermittent namespace contains a set of correlators
that notify you when a network component is flapping. When APA status
change alarms or LinkDown/LinkUp transitions exceed a count
threshold during a specified time interval, flapping events are generated.
One flapping alarm is generated for each type of object (link, node,
interface, address, or connection).
Multiple LinkDown Traps

Correlates LinkDown events from the same source into a single flapping
alarm and forwards the new alarm to the NNM alarm browser.
Behavior
The ECS PairWise correlation deletes LinkDown events from the NNm
alarm browser when a LinkUp event arrives, unless configured
otherwise. Therefore, you may not see these events in the NNM alarm
browser. The OV_Link_Intermittent correlator detects a repetitive
link-down situation and generates an OV_Link_Intermittent alarm to
warn you of a potential problem.
If a LinkDown events arrives and no other LinkDown events have been
received from that same source, a new interval is started. If LinkDown
events already exist for that source, a counter is updated and checked to
see if its count exceeds the configured threshold (default, Count = 3). If
the count exceeds the threshold and the event is received within the
current interval (default, Window Period = 30 minutes), an
OV_Link_Intermittent alarm is generated and forwarded to the NNM
alarm browser. All further LinkDown events for that device within the
time interval are nested under the OV_Link_Intermittent alarm.
Configurable Parameters
The only configurable parameters, by default, are:
• Count
• Window Period
Chapter 7 203
For instructions on how to modify these parameters, see “Setting

Parameters” on page 230. Note that the OV_Link_Intermittent
correlator is contained within the OV_PollerIntermittent namespace.
Node Intermittent Status Change

Identifies nodes that are reporting intermittent up/down status.
Behavior
When APA is enabled, the OV_Node_IntermittentStatus correlator
detects a repetitive node down/up situation and generates an
OV_APA_NODE_Intermittent alarm to warn you of a potential problem.
The OV_Node_IntermittentStatus correlator generates an
OV_APA_NODE_Intermittent alarm if the OV_APA_NODE_DOWN event
occurs a specified number of times (default, Count = 2) during a specified
time interval (default, Window Period = 30 minutes) from the same
node.
If an OV_APA_NODE_DOWN event arrives and no other OV_APA_NODE_DOWN
events have been received from that same node, a new interval is
started. If OV_APA_NODE_DOWN events already exist for that node, a
counter is updated and checked to see if its count exceeds the configured
threshold. If the count exceeds the threshold and the event is received
within the current interval, an OV_APA_NODE_Intermittent alarm is
generated and forwarded to the NNM alarm browser. All further
OV_APA_NODE_DOWN events for that node within the time interval are
nested under the OV_APA_NODE_Intermittent alarm.
Note that, depending on how the ECS PairWise correlation is
configured, you may not see OV_APA_NODE_DOWN and OV_APA_NODE_UP
events in the NNM alarm browser. However, you may see an
OV_APA_NODE_DOWN event in the alarm browser at the same time as the
OV_APA_NODE_Intermittent alarm. The OV_APA_NODE_DOWN event
remains in the alarm browser until the corresponding OV_APA_NODE_UP
event is generated and dismissed by the ECS PairWise correlation.
• Count
• Window Period
204 Chapter 7

Parameters” on page 230. Note that the OV_Node_IntermittentStatus
Interface Intermittent Status Change

Identifies interfaces that are reporting intermittent up/down status.
Behavior
When APA is enabled, the OV_Interface_IntermittentStatus
correlator detects a repetitive interface down/up situation and generates
an OV_APA_IF_Intermittent alarm to warn you of a potential problem.
The OV_Interface_IntermittentStatus correlator generates an
OV_APA_IF_Intermittent alarm if the OV_APA_IF_DOWN event occurs a
specified number of times (default, Count = 2) during a specified time
interval (default, Window Period = 30 minutes) from the same interface.
If an OV_APA_IF_DOWN event arrives and no other OV_APA_IF_DOWN
events have been received from that same interface, a new interval is
started. If OV_APA_IF_DOWN events already exist for that interface, a
within the current interval, an OV_APA_IF_Intermittent alarm is
OV_APA_IF_DOWN events for that interface within the time interval are
nested under the OV_APA_IF_Intermittent alarm.
configured, you may not see OV_APA_IF_DOWN and OV_APA_IF_UP events
in the NNM alarm browser. However, you may see an OV_APA_IF_DOWN
event in the alarm browser at the same time as the
OV_APA_IF_Intermittent alarm. The OV_APA_IF_DOWN event remains
in the alarm browser until the corresponding OV_APA_IF_UP event is
generated and dismissed by the ECS PairWise correlation.
• Count
• Window Period
Chapter 7 205

Parameters” on page 230. Note that the
OV_Interface_IntermittentStatus correlator is contained within the
OV_PollerIntermittent namespace.
Address Intermittent Status Changes

Identifies addresses that are reporting intermittent up/down status.
Behavior
When APA is enabled, the OV_Addr_IntermittentStatus correlator
detects a repetitive address down/up situation and generates an
OV_APA_ADDR_Intermittent alarm to warn you of a potential problem.
The OV_Addr_IntermittentStatus correlator generates an
OV_APA_ADDR_Intermittent alarm if the OV_APA_ADDR_DOWN event
occurs a specified number of times (default, Count = 2) during a specified
time interval (default, Window Period = 30 minutes) from the same
address.
If an OV_APA_ADDR_DOWN event arrives and no other OV_APA_ADDR_DOWN
events have been received from that same address, a new interval is
started. If OV_APA_ADDR_DOWN events already exist for that address, a
within the current interval, an OV_APA_ADDR_Intermittent alarm is
OV_APA_ADDR_DOWN events for that address within the time interval are
nested under the OV_APA_ADDR_Intermittent alarm.
configured, you may not see OV_APA_ADDR_DOWN and OV_APA_ADDR_UP
events in the NNM alarm browser. However, you may see an
OV_APA_ADDR_DOWN event in the alarm browser at the same time as the
OV_APA_ADDR_Intermittent alarm. The OV_APA_ADDR_DOWN event
remains in the alarm browser until the corresponding OV_APA_ADDR_UP
event is generated and dismissed by the ECS PairWise correlation.
• Count
206 Chapter 7
• Window Period
Parameters” on page 230. Note that the OV_Addr_IntermittentStatus
Connection Intermittent Status Change

Identifies connections that are reporting intermittent up/down status.
Behavior
When APA is enabled, the OV_Connection_IntermittentStatus
correlator detects a repetitive connection down/up situation and
generates an OV_APA_CONN_Intermittent alarm to warn you of a
potential problem.
The OV_Connection_IntermittentStatus correlator generates an
OV_APA_CONN_Intermittent alarm if the OV_APA_CONNECTION_DOWN
event occurs a specified number of times (default, Count = 2) during a
specified time interval (default, Window Period = 30 minutes) from the
same source.
If an OV_APA_CONNECTION_DOWN event arrives and no other
OV_APA_CONNECTION_DOWN events have been received from that same
source, a new interval is started. If OV_APA_CONNECTION_DOWN events
already exist for that source, a counter is updated and checked to see if
its count exceeds the configured threshold. If the count exceeds the
threshold and the event is received within the current interval, an
OV_APA_CONN_Intermittent alarm is generated and forwarded to the
NNM alarm browser. All further OV_APA_CONNECTION_DOWN events for
that source within the time interval are nested under the
OV_APA_CONN_Intermittent alarm.
configured, you may not see OV_APA_CONNECTION_DOWN and
OV_APA_CONNECTION_UP events in the NNM alarm browser. However,
you may see an OV_APA_CONNECTION_DOWN event in the alarm browser at
the same time as the OV_APA_CONN_Intermittent alarm. The
OV_APA_CONNECTION_DOWN event remains in the alarm browser until the
corresponding OV_APA_CONNECTION_UP event is generated and dismissed
by the ECS PairWise correlation.
Chapter 7 207
• Count
• Window Period
Parameters” on page 230. Note that the
OV_Connection_IntermittentStatus correlator is contained within the
OV_PollerIntermittent namespace.
208 Chapter 7
OV_PollerLinkDown Namespace
The OV_PollerLinkDown namespace contains a set of correlators that
determine if the root cause of a LinkDown event is a result of a node or
connection going down. When appropriate, the LinkDown events are
correlated under the APA root cause alarm and then removed from the
alarm browser.
LinkDown Events and APA Node Status Alarms

Listens for LinkDown events and OV_APA_NODE_DOWN alarms. LinkDown
events received within M minutes from the same source as the APA node
status alarm are suppressed and nested beneath the APA node status
alarm (default M=10 minutes).
Behavior
When APA is enabled, the OV_LinkDown_NodeDown correlator works with
the OV_Link_Down correlator in the following way:
1. The OV_Link_Down correlator listens for LinkDown events. When a

LinkDown event arrives, the OV_Link_Down correlator generates a
new, enhanced event, OV_Link_Down.
2. The OV_LinkDown_NodeDown correlator listens for OV_Link_Down
events and extracts the associated node IDs from these events.
3. The OV_LinkDown_NodeDown correlator waits for an
OV_APA_NODE_DOWN event to arrive. When an OV_APA_NODE_DOWN
event arrives, the OV_LinkDown_NodeDown correlator extracts the
node ID from the OV_APA_NODE_DOWN event.
4. A set is considered complete when at least one OV_Link_Down event
and one OV_APA_NODE_DOWN event is received from the same node
within a specified window period.
5. When a set is complete, all OV_Link_Down events received during a
specified window period with the same node ID as the
OV_APA_NODE_DOWN event are correlated under the
OV_APA_NODE_DOWN alarm.
6. In addition, the corresponding LinkDown events are removed from
the NNM alarm browser.
Chapter 7 209
The only configurable parameter, by default, is:
• Window Period
For instructions on how to modify this parameter, see “Setting
Parameters” on page 230. Note that the OV_LinkDown_NodeDown
correlator is contained within the OV_PollerLinkDown namespace.
LinkDown Events and APA Connection Status Alarms

Listens for LinkDown events and OV_APA_CONNECTION_DOWN or
OV_APA_CONNECTION_UNREACHABLE alarms. LinkDown events received
within M minutes from the same source as the APA connection status
alarm are suppressed and nested beneath the APA connection status
alarm (default M=10 minutes).
Behavior
When APA is enabled, the OV_LinkDown_ConnDown correlator works with
the OV_Link_Down correlator in the following way:
1. The OV_Link_Down correlator listens for LinkDown events. When a

LinkDown events arrives, the OV_Link_Down correlator generates a
new, enhanced alarm, OV_Link_Down.
2. The OV_LinkDown_NodeDown correlator listens for OV_Link_Down
alarms and extracts the associated node and interface IDs from these
alarms.
3. The OV_LinkDown_ConnDown correlator waits for an
OV_APA_CONNECTION_DOWN or OV_APA_CONNECTION_UNREACHABLE
alarm to arrive. When an OV_APA_CONNECTION_DOWN or
OV_APA_CONNECTION_UNREACHABLE alarm arrives, the
OV_LinkDown_ConnDown correlator extracts the node and interface
IDs from the OV_APA_CONNECTION_DOWN or
OV_APA_CONNECTION_UNREACHABLE alarm.
4. A set is considered complete when at least one OV_Link_Down alarm
and one OV_APA_CONNECTION_DOWN or
OV_APA_CONNECTION_UNREACHABLE alarm is received from the same
source within a specified window period.
210 Chapter 7
5. When a set is complete, all OV_Link_Down alarms received during a

specified window period with the same node and interface IDs as the
OV_APA_CONNECTION_DOWN alarm are correlated under the
OV_APA_CONNECTION_DOWN alarm.
6. In addition, the corresponding LinkDown events are removed from
the NNM alarm browser.
The only configurable parameter, by default, is:
• Window Period
For instructions on how to modify this parameter, see “Setting
Parameters” on page 230. Note that the OV_LinkDown_ConnDown
correlator is contained within the OV_PollerLinkDown namespace.
Chapter 7 211
OV_CiscoBoard Namespace
The OV_CiscoBoard namespace contains a set of correlators that
determine if LinkDown events and syslog Link Down and Line Protocol
Down messages are secondary events to Board Down (or ModuleDown)
events or syslog Board Down messages. Secondary events are correlated
under the root cause event identifying the board (or module) that failed.
LinkDown and Syslog Down Events with Board Down

Events
Correlates secondary board failure events, such as LinkDown and syslog
Link Down, with Board Down events.
Behavior
When a board (or module) fails on a Cisco device, several secondary
events can be generated in addition to the Board Down event. It is
desirable to see the root cause Board Down event identifying the board
that failed. The other secondary events should be correlated beneath the
the root cause board failure alarm. The following correlators help achieve
this:
• The OV_Link_Down and OV_Link_Down2 correlators listen for
LinkDown events, and stores the events based on the board (or
module) ID identified in the event.
• The OV_Syslog_LinkDown correlator listens for syslog Link Down
events and syslog Line Protocol Down events, and stores the events
based on the board (or module) ID identified in the event.
• The OV_Board_Down correlator listens for Board Down (or
ModuleDown) events and stores the events based on the board (or
module) ID identified in the event. It then retrieves all secondary
events with the same board ID and nests them beneath the Board
Down event in the alarm browser.
The following steps demonstrate in more detail how the correlators
function:
1. A board (or module) fails on a Cisco device.
212 Chapter 7
2. A LinkDown event, syslog Link Down event, or syslog Line Protocol

Down event is generated and forwarded to NNM.
3. The board ID is extracted from the event and stored in a table for 1
minute.
4. A Board Down event is generated identifying the board that failed.
5. The board ID of the Board Down event is compared to the board IDs
stored in the table.
6. All matching events are nested under the Board Down event in the
alarm browser.
7. The table cache is cleared.
The suppressed alarms can be viewed from the alarm browser by
double-clicking the root cause Board Down alarm.
No parameters for these correlators are configurable.
LinkDown and Syslog Down Events with Syslog

Board Down Events
Correlates secondary board failure events, such as LinkDown and syslog
Link Down, with syslog Board Down events.
Behavior
When a board (or module) fails on a Cisco device, several secondary
events can be generated in addition to the syslog Board Down event. It is
desirable to see the root cause syslog Board Down event identifying the
board that failed. The other secondary events should be correlated
beneath the root cause board failure alarm. The following correlators
help achieve this:
• The OV_Link_Down and OV_Link_Down2 listen for LinkDown events,
and stores the events based on the board (or module) ID identified in
the event.
events and syslog Line Protocol Down events, and stores the events
based on the board (or module) ID identified in the event.
Chapter 7 213
• The OV_Board_Down_Syslog correlator listens for syslog Board Down

(or ModuleDown) events and stores the events based on the board (or
module) ID identified in the event. It then retrieves all secondary
events with the same board ID and nests them beneath the Board
Down event in the alarm browser.
function:

2. A LinkDown event, syslog Link Down event, or syslog Line Protocol
Down event is generated and forwarded to NNM.
3. The board ID is extracted from the event and stored in a table for 1
minute.
4. A syslog Board Down event is generated identifying the board that
failed.
5. The board ID of the syslog Board Down event is compared to the
board and node object IDs stored in the table.
6. All matching events are nested under the syslog Board Down event in
the alarm browser.
double-clicking the root cause syslog Board Down alarm.
Board Down and Syslog Board Down Events

Correlator
Correlates Board Down events and syslog Board Down events. The first to
arrive is posted to the alarm browser; the other alarms are nested
beneath the first.
214 Chapter 7
Behavior
The Board Down (or ModuleDown) event and the syslog Board Down (or
ModuleDown) event are essentially duplicate events. Thus, it is desirable
to post the first of these events to the alarm browser, and correlate the
other events beneath the first. The OV_Board_Trap_SyslogCorr
correlator helps achieve this.
The OV_Board_Trap_SyslogCorr correlator retrieves the board ID and
node ID values from Board Down and syslog Board Down events stored in
the OV_Board_Down and OV_Board_Down_Syslog correlators. When a
match occurs, the first event to arrive becomes the top-level alarm and
the other event is correlated beneath the top-level alarm.
No parameters for this correlator is configurable.
Chapter 7 215
OV_PollerBoardDown Namespace
The OV_PollerBoardDown namespace contains a set of correlators that
determine if Board Down events or syslog Board Down messages should
be nested under the root cause APA Board Down alarm. When
appropriate, the Board Down events are correlated under the APA Board
Down alarm and then removed from the alarm browser.
Board Down Events with APA Board Failure Alarms

Correlates Board Down events and syslog Board Down events with the
root cause APA Board Down alarm.
Behavior
When a board (or module) fails on a Cisco device, the board failure is
detected by APA and an APA Board Down alarm is generated. Board
Down events are likely to be generated by the Cisco device too. It is
desirable to see the APA root cause alarm identifying the board that
failed with the other Board Down events correlated beneath the root
cause alarm. The following correlators help achieve this:
• The OV_Board_Down correlator listens for Board Down (or
ModuleDown) events and stores the events based on the board (or
module) ID identified in the event and the node object ID extracted
from the topology database.
• The OV_APA_BoardDown correlator listens for APA Board Down
alarms. It then retrieves all Board Down events with the same node
ID and board ID and nests them beneath the APA Board Down
alarm in the alarm browser.
function:

2. A Board Down event is generated and forwarded to NNM.
3. The board ID is extracted from the event and the node ID is
extracted from the topology database. The information is stored in a
table for 330 seconds.
216 Chapter 7
4. An APA Board Down alarm is generated identifying the board that

failed and posted to the Status Alarm category of the NNM alarm
browser.
5. The node object ID and board ID of the APA Board Down alarm is
compared to the board and node object IDs stored in the table.
6. All matching events are nested under the APA Board Down alarm in
the Status Alarms Browser.
double-clicking the root cause APA Board Down alarm.
Syslog Board Down Events with APA Board Failure

Alarms
Correlates syslog Board Down events with the root cause APA Board
Down alarm.
Behavior
When a board (or module) fails on a Cisco device, the board failure is
detected by APA and an APA Board Down alarm is generated. Syslog
Board Down events are likely to be generated by the Cisco device too. It is
desirable to see the APA root cause alarm identifying the board that
failed with the other syslog Board Down events correlated beneath the
root cause alarm. The following correlators help achieve this:
• The OV_Syslog_BoardDown correlator listens for syslog Board Down
events, and stores the events based on the board (or module) ID
identified in the event and the node object ID extracted from the
topology database.
• The OV_APA_BoardDown correlator listens for APA Board Down
alarms. It then retrieves all syslog Board Down events with the same
node ID and board ID and nests them beneath the APA Board Down
alarm in the alarm browser.
function:
Chapter 7 217

2. A Board Down event is generated and forwarded to NNM.
3. The board ID is extracted from the event and the node ID is
extracted from the topology database. The information is stored in a
table for 330 seconds.
4. An APA Board Down alarm is generated identifying the board that
failed and posted to the Status Alarm category of the NNM alarm
browser.
5. The node object ID and board ID of the APA Board Down alarm is
compared to the board and node object IDs stored in the table.
6. All matching events are nested beneath the APA Board Down alarm
in the Status Alarms Browser.
double-clicking the root cause APA Board Down alarm.
218 Chapter 7
OV_PollerTrigger Namespace
The OV_PollerTrigger namespace contain a set of correlators that
trigger an immediate APA poll and analysis of a network entity (of type
node, interface, board, or HSRP group). When certain types of traps or
syslog messages arrive, these correlators generate the appropriate APA
poll trigger request on the network entity. Depending on the type of
event, the correlators may issue a status poll request, a configuration
poll request, or a force poll request.
APA Poll Trigger Requests

Triggers an immediate APA poll and analysis of a network entity.
Behavior
When certain types of events are received from a network device, an APA
poll and analysis should be scheduled immediately instead of waiting for
the next APA poll cycle. These correlators listen for events that are not
monitored by APA and generate the appropriate poll trigger request.
There are three types of network entities that can be specified in the poll
trigger request: node, interface, and board. This informs APA as to which
type of network entity should be polled.
A poll trigger request can be one of four types:
• UP - A poll request to determine if the status of a network entity is

up.
• DOWN - A poll request to determine if the status of a network entity
is down.
• CONFIGURATION - A poll request to determine the status of a
network entity. For example, a configuration poll request might be
made to determine if a node has been rebooted.
• FORCE - A poll request to determine the status of a network device
regardless of current status.
function.
Chapter 7 219
1. A network device forwards an event to the NNM management

station (one of the events listed in the Events column of Table 7-1).
2. A counter is incremented based on the event source and poll type.
3. The correlator generates an APA Demand Analysis event, which
issues a poll trigger request. The type of poll trigger request to be
issued for that event is listed in Table 7-1.
The APA Demand Analysis event is generated only when the
following two criteria are met:
• No other event, such as LinkDown or LinkUp, has been sent

directly to poller.
• No other APA Demand Analysis event for that event source and
poll type has been sent within a specified time window.
4. Another event of the same type from the same source arrives.
5. The counter is incremented.
6. When the window period expires, the counter is cleared.
These events may participate in additional root cause analysis by the
other APA correlators. The events may be correlated under the first
event of its kind, or correlated under the APA alarm that is
generated as a result of the triggered APA polling.
Table 7-1 Events Being Monitored by the APA Poll Trigger Correlators
Issue
Object Type for
Events Type of Poll Trigger to
Trigger Event
APA
LinkDown DOWN No Interface
LinkUp UP No Interface
%LINK-3-UPDOWN: Interface DOWN Yes Interface

[chars] changed state to down
%LINK-3-UPDOWN: Interface UP Yes Interface

[chars] changed state to up
%LINEPROTO-5-UPDOWN : DOWN Yes Interface

Line protocol on Interface [chars],
changed state to down
220 Chapter 7
Issue
Object Type for
Trigger Event
APA
%LINEPROTO-5-UPDOWN : UP Yes Interface

Line protocol on Interface [chars],
changed state to
Board (Module) Down DOWN No Board
Board (Module) Up UP No Board
%SNMP-5-MODULETRAP: DOWN Yes Board

Module [dec] down Trap
%SNMP-5-MODULETRAP: UP Yes Board

Module [dec] up Trap
%SYS-5-MOD_NORESPONSE: DOWN Yes Board

Module [dec] failed to respond
%SYS-5-MOD_OK: Module [dec] UP Yes Board

is online
%SYS-5-MOD_REMOVE: Module CONFIG Yes Board

[dec] has been removed
%SYS-5-MOD_INSERT: Module CONFIG Yes Board

[dec] has been removed
%SYS-5-MOD_RESET: Module CONFIG Yes Board

[dec] reset from [chars]
%SYS-3-MOD_FAIL: Module DOWN Yes Board

[dec] failed to come online
%SYS-3-MOD_FAILREASON: DOWN Yes Board

Module [dec] configuration
mismatch
%SYS-3-MOD_CFGMISMATCH1 CONFIG Yes Board

: Module [dec] configuration
mismatch [chars]
Chapter 7 221
Issue
Object Type for
Trigger Event
APA

: *Config: [chars}

: *Actual: [chars]

: Insert config type module or do a
‘clear config [dec]’
Cold Start CONFIG No Node
Warm Start CONFIG No Node
%SYS-5-RELOAD: Reload None No Node

requested
%SYS-5-RESTART: System CONFIG Yes Node

restarted
%OSPF-5-ADJCHG: Process FORCE Yes Node

[dec], Nbr [int] on [chars] from
[chars] to DOWN
%OSPF-5-ADJCHG: Process FORCE Yes Node

[dec], Nbr [int] on [chars] from
[chars] to FULL
%STANDBY-6-STATECHANGE: FORCE Yes HSRP Group

Standby: [dec]: [chars] state
Active -> Speak

Speak -> Standby

Standby -> Active
222 Chapter 7
Issue
Object Type for
Trigger Event
APA

Standby -> Init
%PAGP-5-PORTTOSPT: Port FORCE Yes Interface

[dec]/[dec] joined bridge port
[dec]/[chars]
%PAGP-5-PORTFROMSPT: Port FORCE Yes Interface

[dec]/[dec] left bridge port
[dec]/[chars]
Chapter 7 223
OV_PollerTriggerCorr Namespace
The OV_PollerTriggerCorr namespace contains a set of correlators
that correlate duplicate poll trigger events not already being correlated
by the other APA correlators. Secondary events are correlated under the
first event to arrive or under the APA alarm that is generated as a result
of the poll request.
OSPF Adjacency Change Events with APA Root Cause

Alarms
Correlates OSPF Adjacency Change events with APA root cause alarms.
Behavior
When APA is enabled, the OV_OSPF_AdjacencyChange correlator works
with the OV_OSPF_APA correlator in the following way:
1. The OV_OSPF_AdjacencyChange correlator listens for OSPF

Adjacency Change events.
2. The node object ID is extracted from topology database and stored in
table for 3 minutes.
3. An APA root cause alarm of the following type is generated and
posted to the Status Alarms category of the NNM alarm browser:
• OV_APA_IF_DOWN
• OV_APA_IF_UP
• OV_APA_IF_UNREACHABLE
• OV_APA_CONNECTION_DOWN
• OV_APA_CONNECTION_UP
• OV_APA_CONNECTION_UNREACHABLE
4. The node object ID of the APA alarm is compared to the node object
IDs of the OSPF Adjacency Change events.
5. All matching OSPF Adjacency Change events are nested beneath
the APA alarm in the Status Alarm Browser.
224 Chapter 7
The suppressed OSPF Adjacency Change events can be viewed from the
Status Alarms Browser by double-clicking the root cause APA alarm.
HSRP State Change Events with HSRP Root Cause

Alarms
Correlates HSRP State Change events with APA HSRP root cause
alarms.
Behavior
When APA is enabled, the OV_HSRP_StateChange correlator works with
the OV_HSRP_APA correlator in the following way:
1. The OV_HSRP_StateChange correlator listens for HSRP State

Change events.
2. The node object ID is extracted from topology database and stored in
table for 5 minutes.
3. An APA root cause alarm of the type OV_HSRP is generated and
posted to the Status Alarms category of the NNM alarm browser.
IDs of the HSRP State Change events.
5. All matching HSRP State Change events are nested beneath the
APA alarm in the Status Alarm Browser.
The suppressed HSRP State Change events can be viewed from the
Status Alarms Browser by double-clicking the root cause APA alarm.
Restart-Type Events with APA Node Status Alarms

Correlates Cold Start/Warm Start events and syslog RELOAD/RESTART
events with APA Node status alarms.
Chapter 7 225
Behavior
When APA is enabled, the OV_NodeRestart_Syslog and
OV_Node_Restart_Trap correlators work with the OV_NodeRestart_APA
correlator in the following way:
1. The OV_NodeRestart_Syslog and OV_Node_Restart_Trap

correlators listen for the following events:
• Cold Start
• Warm Start
• %SYS-5-RELOAD: Reload requested
• %SYS-5-RESTART: System restarted
2. When a restart-type event arrives, the node object ID is extracted
from topology database and stored in table for 3 minutes.
3. An APA root cause alarm of the type OV_APA_NODE_UP or
OV_APA_NODE_RENUMBERING is generated and posted to the Status
Alarms category of the NNM alarm browser.
IDs of the restart-type events stored in the table.
5. All matching events are nested beneath the APA alarm in the Status
Alarm Browser.
The suppressed events can be viewed from the Status Alarms Browser by
double-clicking the root cause APA alarm.
226 Chapter 7
OV_PollerPortAgg Namespace
The OV_PollerPortAgg namespace contains a set of correlators that
determine if LinkDown events and syslog Down events as well as syslog
port aggregation events are secondary events to APA port aggregation
status alarms. Secondary events are correlated under the APA root cause
alarm.
LinkDown Events and Syslog Down Events with APA

Aggregated Port Alarms
Correlates LinkDown events and syslog Link Down and Line Protocol
Down events under the root cause aggregated port alarm generated by
APA.
Behavior
It is desirable to see the root cause APA alarm in the alarm browser with
aggregated port failure events nested under the APA alarm. The
OV_Link_Down, OV_Syslog_LinkDown, and OV_APA_AggregatedPort
correlators help achieve this.
• The OV_Link_Down correlator listens for LinkDown events and stores

the events based on the node object ID extracted from the topology
database.
and Line Protocol Down events and stores the events based on the
node object ID extracted from the topology database.
• The OV_APA_AggregatedPort correlator listens for APA Aggregated
Port alarms. It then retrieves all LinkDown events and syslog Down
events from the correlators that have the same node object ID and
nests them beneath the APA Aggregated Port alarm.
function:
1. An aggregated port fails or its performance is degraded because of an

underlying interface failure on a Cisco device.
2. A LinkDown event, a syslog Link Down event, or a syslog Line
Protocol Down event is generated and forwarded to NNM.
Chapter 7 227
3. The node object ID is extracted from the event and stored in a table
for 1 minute.
4. An APA Aggregated Port alarm is generated and posted to the Status
Alarm category of the NNM alarm browser.
5. The node object ID of the APA Aggregated Port alarm is compared to
the node object IDs stored in the table.
6. All matching events are nested under the APA Aggregated Port
alarm in the Status Alarm Browser.
double-clicking the APA Aggregrated Port alarm.
Syslog Port Aggregation Events with APA Aggregated

Port Alarms
Correlates syslog aggregated port events (PAGP messages) under the
root cause alarm generated by APA.
Behavior
It is desirable to see the root cause APA alarm in the alarm browser with
syslog aggregated port failure events nested under the APA alarm. The
OV_Port_Aggregation and OV_APA_AggregatedPort correlators help
achieve this.
• The OV_Port_Aggregation correlator listens for syslog port

aggregation events (PAGP messages) and stores the events based on
the node object ID extracted from the topology database.
• The OV_APA_AggregatedPort correlator listens for APA Aggregated
Port alarms. It then retrieves all syslog port aggregation events from
the OV_Port_Aggregation correlator that have the same node object
ID and nests them beneath the APA Aggregated Port alarm.
function:
228 Chapter 7
1. An aggregated port fails or its performance is degraded because of an

underlying interface failure on a Cisco device.
2. A syslog PAGP_JoinedBridgePort event or PAGP_LeftBridgePort
event is generated and forwarded to NNM.
3. The node object ID is extracted from the event and stored in a table
for 330 seconds (5.5 minutes).
4. An APA Aggregated Port alarm is generated and posted to the Status
Alarm category of the NNM alarm browser.
5. The node object ID of the APA Aggregated Port alarm is compared to
the node object IDs stored in the table.
6. All matching events are nested under the APA Aggregated Port
alarm in the Status Alarm Browser.
double-clicking the APA Aggregated Port alarm.
Chapter 7 229
Setting Parameters
Setting Parameters
Complete the following steps if you want to review parameter definitions
or modify parameters contained within a Correlation Composer
correlator.
TIP There are several ways to access the event correlation features. For more
information, from any submap, select Tools:HP OpenView Launcher.
Select the [?] tab. Click Tasks, Event Correlation Management. Read
the information under Accessing the Event Correlation Configuration
Windows.
1. From any submap, select Options:Event Configuration. This

launches the Event Configuration window.
2. From NNM’s Event Configuration window, select Edit:Event
Correlation. This brings up the ECS Configuration window.
3. From the ECS Configuration window, select the ‘default’ stream.
Then, highlight Composer in the correlation table and select Modify.
The Correlation Composer window appears in your web browser.
4. In the Correlation Composer window, select the appropriate
namespace from the NameSpace table. Its correlators are displayed
in the Correlator Store.
5. Double-click the correlator to display the Description tab.
6. Carefully read the information in the Description tab.
The configurable parameters are listed in the Description tab. If
you need to modify values of other parameters, open Correlation
Composer in developer mode. See HP OpenView Correlation
Composer's Guide for more information about Correlation Composer
in developer mode.
7. Click the Definition tab to access the configurable parameter
setting. Click [Help] for information about each field.
8. After making the desired change, click [OK] and close the correlator
configuration window and return to the Correlation Composer
main window.
230 Chapter 7
Setting Parameters
9. Save your change by clicking File:Save. This updates the correlator

fact store file associated with the namespace.
10. To activate your change, click File:Close and then click
Correlations:Deploy.
11. Exit the Correlation Composer main window.
Chapter 7 231
Disabling APA Correlators and Correlator Groups
Disabling APA Correlators and Correlator

Groups
For testing purposes or performance reasons, you may want to disable a
correlator or group of correlators. For example, if Syslog Integration is
not enabled, you may want to disable individual syslog-specific
correlators. Moreover, you might find that disabling one correlator
causes other correlators in its group not to be useful anymore, so you
may want to disable the entire group of correlators.
Note that all of the APA correlators are distinct; meaning they work
together to provide a set of functionality, but may be turned on or off
independent of the other correlators.
There are two ways to disable correlators:
• “Disabling a Correlator from the Correlator Store” on page 232

• “Disabling Groups of Correlators” on page 233
Disabling a Correlator from the Correlator Store

Complete the following steps to disable a Correlation Composer
correlator.
TIP There are several ways to access the event correlation features. For more
information, from any submap, select Tools:HP OpenView Launcher.
Select the [?] tab. Click Tasks, Event Correlation Management. Read
the information under Accessing the Event Correlation Configuration
Windows.
1. From any submap, select Options:Event Configuration. This

2. From NNM’s Event Configuration window, select Edit:Event
3. From the ECS Configuration window, select the ‘default’ stream.
Then, highlight Composer in the correlation table and select Modify.
The Correlation Composer window appears in your web browser.
232 Chapter 7
4. In the Correlation Composer window, select the appropriate

namespace from the NameSpace table. Its correlators are displayed
in the Correlator Store.
5. To disable a correlator, click within the box in the Enable column for
that correlator in the Correlator Store.
6. Save your change by clicking File:Save. This updates the correlator
factstore file associated with the namespace.
7. To activate your change, click File:Close and then click
Correlations:Deploy.
8. Exit the Correlation Composer main window.
Disabling Groups of Correlators

The APA correlators are divided into logical groups called namespaces.
Each namespace is associated with a factstore file, which contains the
definitions of the correlators. The association of the factstore file with a
namespace is in the Correlation Composer namespace file,
NameSpace.conf.
The factstore files and the Correlation Composer namespace file,
NameSpace.conf, are located in:
Windows: \NNM_install_dir\ecs\CIB\
UNIX: $OV_CONF/ecs/CIB/
To disable a group of Correlation Composer correlators, remove the
namespace/factstore file pair from the NameSpace.conf file as detailed
below.
1. Open the Correlation Composer namespace file, NameSpace.conf.

2. Identify the namespace or the factstore file containing the group of
correlators that you want to disable. For example, the correlators
that trigger APA poll requests are defined in the PollerTrigger.fs
factstore file. Its associated namespace is PollerTrigger.
3. Remove the entry in NameSpace.conf that associates the factstore
file with its namespace. For example, to remove the APA Poll Trigger
correlators, delete the line: PollerTrigger=PollerTrigger.fs
4. Save the NameSpace.conf file.
5. Deploy the correlations to activate your changes.
Chapter 7 233
a. From any submap, select Options:Event Configuration. This

b. From NNM’s Event Configuration window, select Edit:Event
c. From the ECS Configuration window, select the ‘default’
stream. Then, highlight Composer in the correlation table and
select Modify. The Correlation Composer window appears in
your web browser.
d. Make sure all files are closed and click Correlations:Deploy.
e. Exit the Correlation Composer main window.
234 Chapter 7
Troubleshooting
Troubleshooting
For troubleshooting information about the Correlation Composer, see the
following references:
• Access the following pdf format manual from the NNM main window,
select Help:Documentation:
— HP OpenView Correlation Composer's Guide
Chapter 7 235
Troubleshooting
236 Chapter 7
8 The Advanced Routing Smart
Plug-in
Chapter 8 237
The Advanced Routing Smart Plug-in
What the Advanced Routing Smart Plug-in Discovers
What the Advanced Routing Smart Plug-in

Discovers
The Advanced Routing SPI (Smart Plug-in) enables Extended Topology
to discover information about HSRP groups, OSPF areas, and devices
that support IPv6. You must purchase and install a license for the
Advanced Routing SPI to use this functionality. To review additional
network SPIs, point your browser to http://openview.hp.com and follow
the links to OpenView products.
Discovering HSRP Information

The Advanced Routing SPI enables Extended Topology to discover and
display HSRP information from managed devices that support the HSRP
protocol.
While HSRP discovery is automatic, there are important preliminary
steps you need to take to assure correct HSRP discovery and monitoring.
If you want to discover and monitor HSRP groups, see “Running HSRP
Discovery” on page 257 for details.
The Active Problem Analyzer polls HSRP routers and reports HSRP
group status information. See“Understanding HSRP View Status
Information” on page 260 for more information.
Once HSRP discovery and monitoring is functional, see “Using the HSRP
View to Diagnose Network Problems” on page 263 or the HP OpenView
web online help for information on using this feature.
Discovering OSPF Information

display OSPF information. OSPF discovery is a separate process from
the Extended Topology discovery. You run OSPF discovery by using a
manual discovery procedure. See “Running OSPF Discovery” on
page 252 for more information about OSPF discovery.
Another product, the HP OpenView Route Analytics Management
System (RAMS), together with the NNM/RAMS Integration Module,
represents a superior solution to OSPF management. By actively
participating in the network protocols, RAMS provides near real-time
238 Chapter 8
What the Advanced Routing Smart Plug-in Discovers
routing data across multiple protocols. Coupled with NNM Advanced

Edition, it greatly enhances the root-cause analysis and visualization of
your OSPF routing fabric.
Discovering IPv6 Information

display IPv6 information. When you run IPv6 discovery, Extended
Topology discovers global, site-local, and link-local addresses. The
management station and all routers must be dual-stacked for IPv6
discovery to function properly.
To prepare the Advanced Routing SPI for IPv6 discovery, you must run
the following script:
• Windows:%OV_BIN%\setupExtTopo.ovpl
• UNIX:$OV_BIN/setupExtTopo.ovpl
See “Running IPv6 Discovery” on page 240 for more information.
Chapter 8 239
Running IPv6 Discovery

Before starting your IPv6 discovery, you need add some information to
three files as described below.
The following five files control your IPv6 discovery and status polling:
• Windows:
%OV_CONF%\nnmet\IPv6.conf
%OV_CONF%\nnmet\IPv6Polling.conf
%OV_CONF%\nnmet\IPv6Prefix.conf
%OV_CONF%\nnmet\IPv6Scope.conf
%OV_CONF%\nnmet\IPv6Seed.conf
• UNIX:
$OV_CONF/nnmet/IPv6.conf
$OV_CONF/nnmet/IPv6Polling.conf
$OV_CONF/nnmet/IPv6Prefix.conf
$OV_CONF/nnmet/IPv6Scope.conf
$OV_CONF/nnmet/IPv6Seed.conf
You configure these files to adjust discovery and polling to meet your
needs. Each file contains configuration examples and instructions
showing how to add information. Use the following procedure to
complete your IPv6 discovery:
1. Modify the IPv6Seed.conf file.

The Advanced Routing SPI uses the IPv6Seed.conf file to seed your
IPv6 discovery. For best results, enter the addresses of all of the
routers and end nodes you want to discover into this file. To enter
these addresses, follow the instructions included within the
IPv6Seed.conf file.
2. This step is not mandatory. The Advanced Routing SPI reads routing
tables from routers and can discover devices beyond the nodes
specified in the IPv6Seed.conf file. If you want to limit IPv6
discovery to the nodes you add to this file, edit the IPv6.conf file and
follow the instructions contained in the file.
240 Chapter 8
3. Modify the IPv6Prefix.conf file.

IPv6 prefix groups are similar to subnets in IPv4. The
IPv6Prefix.conf file is used to give a user-friendly name to your
prefix groups once they are discovered.
4. This step is not mandatory. The Advanced Routing SPI allows you to
list prefix groups and IPv6 addresses that you either want discovered
or want excluded from discovery. To enter these addresses or prefix
groups, follow the instructions included within the IPv6Scope.conf
file.
5. This step is not mandatory. You can modify the IPv6Polling.conf
file if you need to change the polling frequency.
The IPv6Polling.conf file is used to modify the polling frequency of
nodes.
6. If you are installing Extended Topology for the first time, you need to
execute the following script and follow the instructions.
Windows: %OV_BIN%\setupExtTopo.ovpl
UNIX: $OV_BIN/setupExtTopo.ovpl
Once you complete this step, you just started your first discovery.
There is no need to complete step 5. See “Running Extended
Topology Discovery” on page 23 for more information about the
setupExtTopo.ovpl script.
7. If you v the setupExtTopo.ovpl script prior to configuring your IPv6
discovery, you need to execute, as Administrator or root, the
following script:
Windows: %OV_BIN%\etrestart.ovpl
UNIX: $OV_BIN/etrestart.ovpl
This will start a new Extended Topology discovery.
NOTE IPv6 discovery relies heavily on both forward and reverse name
resolution. You can achieve name resolution by using either a DNS
server or hosts files. Make sure all of your IPv6 addresses resolve
properly before proceeding.
Execute the IPv6NameByAddr command as follows to check reverse name
resolution:
Chapter 8 241
Windows: the support directory and tools are located on the product CD.
UNIX: /opt/OV/support/NM/getIPv6NameByAddrIPv6Addr
See “Troubleshooting IPv6 Discovery” on page 242 for more information

about diagnosing IPv6 discovery problems.
Troubleshooting IPv6 Discovery

Some common IPv6 discovery errors are listed below:
• Unexpected nodes show up in your map: The Advanced Routing SPI

discovers IPv6 nodes beyond the seed file entries. Extra IPv6 nodes
will show up if they are found in the router’s tables.
• Some nodes are missing from the map: Make sure these nodes are
entered in the following file:
Windows:%OV_CONF%\nnmet\IPv6Seed.conf
UNIX:$OV_CONF/nnmet/IPv6Seed.conf
That’s the only way to ensure that the Advanced Routing SPI will
discover these nodes. Make sure you enter only valid nodes in the
IPv6Seed.conf file.
• Extended Topology shows a node’s status as being down when you
know the node is up: Extended Topology relies on the Advanced
Advanced Routing SPI’s IPv6 ping for all its status. Make sure you
can IPv6 ping all of the node’s IPv6 addresses from the management
station.
• The map shows your end nodes labeled with IPv6 Addresses rather
than names: Make sure that both forward and reverse DNS are
working for the node from the management station.
• Your routers are showing up as end nodes instead of routers: Make
sure this is a supported router with IPv6 MIBs loaded. For
information about how to find out which IPv6 devices the Advanced
Routing SPI supports, see “Obtaining Supported Device Information”
on page 276. Also make sure you have SNMP access properly
configured.
• Your map shows prefix groups connected to the router but no end
nodes in the prefix groups. There are several possible solutions listed
below:
242 Chapter 8
— You may have the End Nodes check box deselected in the view.
— The router may be the only node in the prefix group. This is
common for routers. Many times routers have prefix groups
configured but no end nodes in them yet.
— There may be very little traffic on the network. To remedy this,
specify nodes in the following file for that prefix group:
Windows: %OV_CONF%\nnmet\IPv6Seed.conf
UNIX: $OV_CONF/nnmet/IPv6Seed.conf
• Your topology contains many disconnected nodes: Make sure you can
access your router via SNMP from the management station. Also,
make sure the IPv6 routers you are discovering support the IPv6
MIBs.
• Your topology looks incorrect on the map. There are several possible
solutions listed below:
— Reload the page. If you bring up the page while a lot of status
events are being generated, the topology shows up incorrect.
— Make sure the prefix length is correct for the addresses in the
seed file.
Properly Displaying Routers not Supporting IPv6

MIBs
If you attempt to discover a router that doesn’t support the IPv6 MIBs,
the router can show up as two different nodes. To try and show the router
properly, take the following steps:
1. Ensure that all IPv6 interface addresses are registered on your DNS
server with the same name.
2. Ensure that at least one IPv4 interface of the router is also
registered on your DNS server under the same name.
3. Ensure that you have configured the SNMP community strings in
NNM for the IPv4 interface of the router.
4. Ensure that all IPv6 addresses and prefix lengths for the router are
listed in the following file without specifying an optional name.
• Windows: %OV_CONF%\nnmet\IPv6Seed.conf
Chapter 8 243
• UNIX: $OV_CONF/nnmet/IPv6Seed.conf
5. Identify all end nodes located beyond the router that you wish to
manage and enter their addresses in the IPv6Seed.conf file since
these end nodes won’t get discovered automatically. Do not enter the
link-local addresses of these nodes.
Properly Displaying IPv6 Nodes with Multiple

Addresses
If you configure a node with more than one IPv6 address you should list
all of the IPv6 addresses for this end node in the following file:
• Windows:%OV_CONF%\nnmet\IPv6Seed.conf
• UNIX: $OV_CONF/nnmet/IPv6Seed.conf
Make sure that your IPv6 addresses are configured as follows:
1. Make sure that all IPv6 addresses for this node are registered on
your DNS server with the same name.
2. Make sure that all IPv6 addresses for this node are listed in the seed
file without specifying an optional name.
Viewing IPv6 Information

You can access an index of all the NNM and Extended Topology views by
pointing your web browser to the following URL:
• http://hostname/:7510
From this index you can access the IPv6 Network View and the IPv6
information.
NOTE There are several other ways to view IPv6 Information. See “Accessing
Dynamic Views” on page 16 for additional information.
IPv6 Network View

If you select the IPv6 Network View from Home Base, the Advanced
Routing SPI displays a global map showing all discovered IPv6 global
prefix groups and the nodes logically connected to each prefix group.
244 Chapter 8
The IPv6 Network View displays nodes having Global addresses, also
called aggregatable global unicast addresses. These addresses refer to
IPv6 addresses that begin with 001.
The Advanced Routing SPI groups IPv6 nodes according to prefix groups,
which are similar to subnets in IPv4. If your DNS is resolving names
properly, you will see nodes with names rather than addresses. If DNS is
not resolving names properly, your views will contain one of the node’s
IPv6 addresses.
You can move your mouse over a node to display additional information.
If you double-click on a node, the Advanced Routing SPI displays details
about that node. Node status is updated dynamically. See
“Understanding IPv6 Status Information” on page 248 for more
information on how the Advanced Routing SPI determines node status.
The default setting for Scope has both the Global option button and the
Include End Nodes check box selected. If you want to restrict the view
to network nodes without end nodes, uncheck the check box and select
[Refresh].
If you want to see only site-local nodes, click the Site-local radio
button and select [Refresh]. For more information see “IPv6 Site-Local
Network View” on page 248.
If you use IPv4 compatible addresses, be aware that IPv4 compatible
status is not shown in the table. You can select any of the interface links
to get all the related status information for any of the interfaces.
Prefix Groups Along with routers and end-nodes, the Advanced

Routing SPI allows Extended Topology to display prefix groups. Prefix
groups are similar to subnets in IPv4. All nodes that have addresses
belonging to a specific prefix group are shown as being connected to that
prefix group’s icon.
The Advanced Routing SPI allows you to name your prefix groups in the
following file in order to provide better segmentation of your IPv6 views.:
• Windows:%OV_CONF%\nnmet\IPv6Prefix.conf
• UNIX: $OV_CONF/nnmet/IPv6Prefix.conf
See “Running IPv6 Discovery” on page 240 for more information on
configuring your prefix group names.
Chapter 8 245
NOTE Link-local addresses are not assigned a prefix group and will not show up
in the map unless their parent nodes also have a global or site-local
address. The Advanced Routing SPI never polls link-local addresses for
status.
IPv6 nodes can have more than one address per interface. In IPv6 views,
connection lines between nodes and prefix groups do not always
represent a one-to-one mapping to interfaces on a node. A single
interface can have multiple addresses which may be in two different
prefix groups.
Refer to Table 8-1 on page 247 when reviewing the following possible
examples:
• If a node has one interface and that interface has one global address,
the Advanced Routing SPI displays only one line connecting the node
to one prefix group.
• If a node has one interface and has two global addresses within the
same prefix group, the Advanced Routing SPI displays only one line
connecting the node to one prefix group.
• If a node has one interface and has two global addresses with two
different prefixes, the Advanced Routing SPI displays two lines
connecting the node to two different prefix groups.
• If a node has two interfaces and a total of four global addresses
belonging to three different prefix groups, the Advanced Routing SPI
displays three lines connecting the node to three different prefix
groups.
246 Chapter 8
Table 8-1 Prefix Group Scenarios
Global
Inter-
Node Address Prefix
Description face Expected Result View
Count Count Count
Count
A node has one 1 1 1 1 The node has one

interface and that line going to the
interface has one prefix group Node
global address. symbol.
Prefix
Group
A node has one 1 1 2 1 The node has one

interface and the line going to the Node
interface has two corresponding
global addresses prefix group
within the same symbol. Prefix
Group
prefix.
A node has one 1 1 2 2 The node has two

interface and the lines going to the
Node
interface has two two prefix group
global addresses symbols.
with different Prefix
Group
prefixes. Prefix
Group
A node has two 1 2 4 3 The node has

interfaces and a three lines going
total of four global to three prefix Node
addresses group symbols.
belonging to three Prefix
Group
different prefixes. Prefix
Group
Prefix
Group
Chapter 8 247
The status of a prefix group is compounded from the status of the

addresses belonging to the prefix group. For example, suppose a prefix
group icon is colored blue. This means that there is an address that is not
responding to IPv6 pings within that prefix group. See “Understanding
IPv6 Status Information” on page 248 for more information on
understanding IPv6 node status.
IPv6 Site-Local Network View From Home Base, if you select

the IPv6 Network View, then select a Site Local Network View, the
Advanced Routing SPI displays a site-local map, showing all discovered
IPv6 site-local prefix groups and the nodes logically connected to each
prefix group.
If you double-click on a site-local prefix group, you can view the nodes
contained within that site-local prefix group. You can double-click on a
prefix group and view information about each of the nodes in that prefix
group.
Understanding IPv6 Status Information To monitor the

address status of a device, the Advanced Routing SPI uses an IPv6 ping
rather than using SNMP requests. The Advanced Routing SPI considers
a device to be down if it doesn’t respond to an IPv6 ping.
You can modify the following file to adjust the IPv6 ping frequency:
• Windows: %OV_CONF%\nnmet\IPv6Polling.conf
• UNIX: $OV_CONF/nnmet/IPv6Polling.conf
NOTE The Advanced Routing SPI does not ping link-local addresses and marks
any link-local address with an UNKNOWN status.
IPv6 site-local and global addresses have three status possibilities:

normal, critical, or unknown. The Advanced Routing SPI derives
interface status from address status and node status from interface
status. From these address status, we derive interface status. The
248 Chapter 8
Advanced Routing SPI also derives prefix group status from address
status. See Table 8-2 for a summary of how the Advanced Routing SPI
compounds IPv6 status information.
Table 8-2 Deriving IPv6 Status
Address Status Interface Status Node Status
Site-local address Site-local interface Site-local node

status status status
Global address Global interface Global node status

status status
Site-local plus Overall interface Overall node status

global address status
status
NOTE The status of an IPv4-compatible address contributes to the overall

interface status it is assigned to. This can also impact the overall node
status.
The Advanced Routing SPI derives interface status using the

compounding rules show in Table 8-3.
Table 8-3 Compound IPv6 Address Status into Interface Status
Compounded
Current Address Status
Interface Status
Any address status is down. Down
All address statuses are unknown. Unknown
At least one address status is up and all Normal

other address statuses are unknown.
Chapter 8 249
The Advanced Routing SPI derives interface status using the

compounding rules show in Table 8-4 on page 250
Table 8-4 Compounding IPv6 Address Status
Compounded
Condition of Contributing Objects
Status
No Objects Exist Unknown (blue)
All are unknown Unknown (blue)

All are up (except those that are Normal (green)
unknown)
One is down and all others are up Warning (cyan)

(except those that are unknown)
More than one is up and more than one Minor/Marginal

is down (except the ones that are (yellow)
unknown)
One is up and all others are down Major (orange)

(except the ones that are unknown)
All are down (except the ones that are Critical (red)
unknown)
See the Understanding IPv6 Status section of the HP OpenView web

online help for more information.
Understanding IPv6 Events

The Advanced Routing SPI generates many new IPv6 events. Most of
these events are logged and not forwarded to the NNM Alarm Browser.
You can open an IPv6 view from events located in the NNM Alarm
Browser, by selecting Actions->Views->IPv6.
The Advanced Routing SPI displays one event, OV_IPV6_Address_DOWN,
in the NNM Alarm Browser. NNM includes both the
OV_IPV6_Address_DOWN and OV_IPV6_AddressUP events in the
Pairwise event correlation. For more information about the behavior of
the NNM Event Correlation System and the Pairwise event correlation,
250 Chapter 8
see Managing Your Network with HP OpenView Network Node Manager.

For more information about events and their definitions, see the
trapd.conf manpage.
Supported Routers
See “Obtaining Supported Device Information” on page 276 for
information about which devices the Advanced Routing SPI supports.
Chapter 8 251
Running OSPF Discovery

Running OSPF discovery results in the Advanced Routing SPI
discovering OSPF information about your network.
During OSPF discovery, the Advanced Routing SPI reads information
from one of two OSPF version 2 MIBs: RFC1850 or RFC1253. Routing
devices must support one of these MIBs for the Advanced Routing SPI to
read OSPF information from them.
During the OSPF discovery, the Advanced Routing SPI discovers which
area OSPF devices are located in, and how these areas relate to one
another.
You must manually run OSPF discovery as outlined in the following
procedure:
1. Edit the following file using the guidelines listed below:

Windows:%OV_CONF%\nnmet\Ospf.cfg
UNIX:$OV_CONF/nnmet/Ospf.cfg
There are OSPF configuration instructions included within the
Ospf.cfg file. Use the following guidelines to configure the Ospf.cfg
file.
• Add the IP address of a router being managed by NNM to seed

OSPF discovery.
• You can set the OSPF discovery range using either an OSPF area
INCLUDE or EXCLUDE list, but not both, as shown in the
Ospf.cfg file.
• If you use an INCLUDE list, the Advanced Routing SPI discovers
only the areas in the INCLUDE list.
• If you use an EXCLUDE list, the Advanced Routing SPI
discovers all areas except those on the EXCLUDE list.
2. Run the following script:
Windows: %OV_BIN%\ospfdis.ovpl
UNIX: $OV_BIN/ospfdis.ovpl
252 Chapter 8
You must run ospfdis.ovpl each time you modify the Ospf.cfg file
for OSPF discovery changes to affect the OSPF view.
3. Once OSPF discovery completes with no errors shown on your
screen, check for errors in the following file:
Windows: %OV_PRIV_LOG%\ospfdis.err
UNIX: $OV_PRIV_LOG/ospfdis.err
4. If there are errors in the ospfdis.err file, fix any errors that may
impact any devices or areas you are interested in viewing and rerun
the ospfdis.ovpl command.
5. Repeat step 4 until you are satisfied with your OSPF view.
Troubleshooting OSPF Discovery

Someone knowledgeable about OSPF and the discovered environment
should remedy problems found in the ospfdis.err file. Some common
OSPF discovery errors are:
• Device access problems: Device SNMP community strings are

missing or incorrect. Find and add the device community names
using NNM’s SNMP Configuration menu item from the NNM
Options menu. This could be the source of numerous ospfdis.err
file entries.
• Seed device is inaccessible: Make sure the seed device you add to the
Ospf.cfg file has been discovered by NNM and is accessible from the
system that the Advanced Routing SPI is running on.
• Discovered device is inaccessible: Make sure the device has been
discovered by NNM and is accessible from the system the Advanced
Routing SPI is running on.
• No seed in the Ospf.cfg file: Edit the Ospf.cfg file and add a seed
router IP address.
• The Advanced Routing SPI expecting IP addresses: Make sure the
seed router IP address is valid.
• Using both INCLUDE and EXCLUDE area lists: Make sure you
have not configured both an INCLUDE and an EXCLUDE area list.
• INCLUDE or EXCLUDE area list errors: Make sure you configure
the lists correctly in the Ospf.cfg file.
Chapter 8 253
Using the OSPF View to Review Network

Configurations
The following scenario shows an example of using the Advanced Routing
SPI information to investigate an OSPF configuration question.
Suppose you wanted to make sure the Area Border Routers you set up for
your network were configured correctly. You know you configured
interfaces on c8kloop to act as the Area Border Routers for both Area
0.0.0.0 and Area 0.0.0.1 .
To check this, you could open an OSPF view from Home Base and
investigate. Figure 8-1 and Figure 8-2 on page 255 show both areas
configured as you designed them.
Figure 8-1 Checking the Area Border Router of Area 0.0.0.1
254 Chapter 8
Figure 8-2 Checking the Area Border Router of Area 0.0.0.0
To review additional information about each area, you can select the All
Areas tab. Figure 8-3 on page 256, shows some of the additional
information that is available. You can use this view to research
additional information such as the OSPF link metric and router status.
Chapter 8 255
Figure 8-3 Additional Information from the All Areas Tab
256 Chapter 8
Running HSRP Discovery

HSRP permits two or more routers (in an HSRP Group) to act as a single
virtual router. Routers in an HSRP Group share a virtual IP address and
a virtual MAC address.
Each router has a corresponding actual IP address on the interface that
is participating in the HSRP Group.
For the HSRP feature to work well, the following conditions must be
true:
• NNM must not attempt to discover and manage the virtual IP

address of an HSRP Group.
• NNM must manage the actual IP address of router interfaces in the
HSRP Group.
NNM meets both of those conditions, internally tracking the virtual IP
address of an HSRP group while managing the actual IP address of
router interfaces in the HSRP Group.
Checking NNM for Correct Handling of HSRP Virtual

IP Addresses
To make sure NNM is configured for correctly handling HSRP virtual
addresses, use the following procedure:
1. As Administrator or root, edit the following file:

• Windows:%OV_LRF%\netmon.lrf
• UNIX: $OV_LRF/netmon.lrf
2. Look for the following text within the file and verify that the bold
text is present.
OVs_YES_START:ovtopmd,pmd,ovwdb:-P -k segRedux=true -k migrateHsrpVirtualIP=true
:OVs_WELL_BEHAVED:15:PAUSE
3. If the bold text is present, then NNM is handling the HSRP virtual
IP address correctly.
4. If the bold text is not present add the text and save the file. You also
need to restart the netmon process as follows:
Chapter 8 257
As Administrator or root, do the following:
a. Run the ovstop netmon command.

b. Run the ovaddobj netmon.lrf command.
c. Run the ovstart netmon command.
HSRP Discovery with Pre-existing NNM Topology

If you already have an NNM topology database (for example, if you have
installed NNM and proceeded with an automatic discovery of your
network), and the contents of the netmon.lrf shows
migrateHsrpVirtualIP=false or doesn’t contain the
migrateHsrpVirtualIP parameter, then the database is likely to
contain the virtual IP addresses of your HSRP groups. This is especially
true if you used NNM’s auto-discovery feature.
You have two tasks:
1. Verify that NNM is correctly managing HSRP virtual IP addresses in

your environment.
2. Remove from NNM any HSRP virtual IP addresses that NNM
currently manages.
The next sections explain the procedure you should follow.
Verifying that NNM is Properly Managing HSRP Virtual IP

Addresses
Follow the procedure shown in “Checking NNM for Correct Handling of
HSRP Virtual IP Addresses” on page 257.
Remove Virtual IP Addresses from the NNM Topology

Next you need to remove any virtual IP addresses from the existing
NNM topology data. There are a couple of common ways to do this:
• Use the following command to completely delete the router from the
database (deleted routers get re-discovered in the next step, but
without their virtual interfaces):
Windows: %OV_BIN%\ovtopofix -r
UNIX: $OV_BIN/ovtopofix –r
258 Chapter 8
You should remove the node (using the NNM ID) rather than the IP
address. The NNM ID can be obtained with the following command:
Windows: %OV_BIN%\ovtopodump
UNIX: $OV_BIN/ovtopodump
See the ovtopofix(1M) and ovtopodump(1M) reference pages in
NNM’s online help (or the UNIX manpages) for details on using
these commands.
• Alternatively, from the NNM graphical interface (ovw), find each of
your HSRP routers. Open each one to show all its interfaces. Delete
the interface that corresponds to the virtual IP address.
Validating Your Results

To verify that your HSRP discovery is correct, run another Extended
Topology discovery, using the following command:
Windows: %OV_BIN%\etrestart.ovpl
UNIX: $OV_BIN/etrestart.ovpl
When the discovery finishes, open the HSRP Group Detail screen for
each group and check for the following:
• If the HSRP virtual IP address shows up in both the IP Interface

column and the Group Membership column, NNM is most likely
managing the virtual IP address. You need to remove this interface
from NNM (see “Remove Virtual IP Addresses from the NNM
Topology” on page 258).
• You may see an HSRP Group with only one router, even though an
HSRP Group must have at least two routers. This could have several
causes. To resolve the problem, do the following:
— Ensure that the actual IP address of the missing HSRP router is

in NNM by running the following command:
Windows: %OV_BIN%\ovtopodump actual_IP_address
UNIX: $OV_BIN/ovtopodump actual_IP_address
— Make sure that NNM has SNMP access to the missing router
— Rerun discovery when all the HSRP router interfaces are up
Chapter 8 259
Note that if an HSRP router interface is down during discovery, the

Advanced Routing SPI will discover HSRP groups incompletely. This
is because the HSRP MIBs at the time of discovery reflect the actual
state. This should be a transient problem that resolves when an
Extended Topology discovery occurs after the interface is back up.
Understanding HSRP View Status Information

The Active Problem Analyzer polls HSRP routers and reports HSRP
group status information. See Table 8-5 on page 261 for a list of the
various group status colors and their meanings.
260 Chapter 8
Table 8-5 HSRP Group Status
HSRP Group
HSRP Group Status Description
Status Color
Unknown The HSRP group has not been polled since

(blue) discovery completed, so the state of the group has
not been determined yet.
The actual state of this HSRP group will be
displayed as soon as it is polled.
Normal The HSRP group is correctly configured and

(green) operational.
This HSRP group is providing routing functionality,
and all standby routers are available.
Warning The HSRP group has an interface in the Active

(cyan) state, and an interface in the Standby state, but it
also has at least one interface that is not in the
Listen state.
This HSRP group is providing routing functionality.
However, one or more standby routers are definitely
unavailable.
Minor or The HSRP Group has an interface in the Active

Marginal state, but there is no interface in the HSRP group
(yellow) which is in the Standby state.
This HSRP group is providing routing functionality,
but there is no standby router available.
Major Multiple interfaces in the HSRP group are in the
(orange) Active state, or multiple interfaces in the HSRP
group are in the Standby state.
This HSRP group is not functioning correctly. There
is almost certainly a problem with routing
functionality.
Critical (red) The HSRP group has no interface in the Active

state.
This HSRP group is definitely not providing routing
functionality.
Chapter 8 261
The Active Problem Analyzer displays the following alarms in the alarms
browser.
• OV_HSRP_No_Active: The reported HSRP group is completely

inoperational.
• OV_HSRP_Multiple_Active: The reported HSRP group is in an
abnormal condition as there are multiple active interfaces.
• OV_HSRP_No_Standby: The reported HSRP group has no standby
interface.
• OV_HSRP_Degraded: The reported HSRP group has an interface that
is not functioning properly
• OV_HSRP_FailOver: The reported HSRP group has changed it active
interface.
• OV_HSRP_Standby_Changed: The reported HSRP group has changed
its standby interface.
• OV_HSRP_Normal:The reported HSRP group is now functioning
normally.
See the trapd.conf reference page in NNM’s online help (or the UNIX
Potential Status Anomalies

Subtle conditions can lead the Advanced Routing SPI to yield unexpected
status for HSRP groups.
• If you run an Extended Topology discovery while any HSRP group

interfaces are down, Extended Topology will not discover all of the
HSRP group interfaces and will calculate and display HSRP group
status using incomplete information. Once you run an Extended
Topology discovery that finds all of the HSRP group’s router
interfaces, Extended Topology will show accurate HSRP status.
CAUTION As you add equipment with new HSRP virtual IP addresses to your
managed environment, you need to add these addresses to the
netmon.noDiscover file prior to turning on the new equipment. If you
262 Chapter 8
fail to do this, and NNM discovers these virtual IP addresses, you will
need to complete the tasks explained in“HSRP Discovery with
Pre-existing NNM Topology” on page 258.
Using the HSRP View to Diagnose Network Problems

The following scenario gives one example of using Extended Topology
information to diagnose an network problem with HSRP. This discussion
assumes you are familiar with HSRP. For detailed information about
HSRP, refer to RFC2281.
Suppose you have two directly connected router interfaces, interface a on
router 1 and interface b on router 2. This discussion refers to these
router interfaces as interfaces 1.a and 2.b respectively.
Assume both interfaces are located within the same LAN segment. You
have router interface 1.a configured as active and router interface 2.b
configured as standby for standby group a.b.c.d. a.b.c.d represents the
virtual IP address of the standby group.
In this example, interface 1.a fails, and the following situation occurs:
1. Interface 2.b becomes active and generates an OV_HSRP_FailOver

alarm.
2. To investigate this alarm, you open an HSRP Group view by selecting
the OV_HSRP_Failover alarm in the Alarm Browser and use the
Actions:Views-> HSRP Group Detail menu.
3. The HSRP Group Detail view shows you that interface 2.b is now
active and interface 1.a is down. You need to troubleshoot interface
1.a.
Chapter 8 263
For More Information
For More Information

If you need more information about IPv6 and OSPF concepts, the
following reference material may be helpful.
Books
Moy, John T. OSPF: Anatomy of an Internet Routing Protocol. Reading,
Mass: Addison-Wesley, 1998. To order, reference ISBN 0-201-63472-4.
Bassam, Halabi. Internet Routing Architectures. Indianapolis, IN: New
Riders Publishing, 1997. To order, reference ISBN 1-56205-652-2.
Loshin, Pete. IPv6 Clearly Explained. San Francisco, CA: Morgan
Kaufmann Publishers, Inc., 1999. To order, reference ISBN
0-12-455838-0.
264 Chapter 8
9 Diagnosing Network Problems
with Extended Topology
Chapter 9 265
Diagnosing Network Problems with Extended Topology
Viewing Extended Topology and NNM Views Using the NNM Alarm Browser
Viewing Extended Topology and NNM Views

Using the NNM Alarm Browser
Alarms arriving in the NNM Alarm Browser often point you to network
access problems. Extended Topology helps you troubleshoot network
access problems caused by a device malfunction or configuration error.
This chapter presents several examples of how you might use Extended
Topology to diagnose network problems. These examples are short
troubleshooting scenarios, and do not show all of the many ways to use
Extended Topology to troubleshoot your network.
Using the Neighbor View to Diagnose Network

Problems
The following scenario gives an example of using Extended Topology
information to diagnose a network problem.
Suppose you saw the highlighted alarm in Figure 9-1 on page 267 in your
NNM Alarm Browser. It seems to indicate a problem with one of your
routers.
266 Chapter 9
To investigate, you could open an NNM Neighbor view by highlighting

this alarm in the Alarm Browser and using the Actions:Views
->Neighbor menu.
Figure 9-1 The Node status - marginal Alarm to Investigate
Figure 9-2 shows a section of the Neighbor view you just opened. Notice
the fat trunk line between 4kfcc5lc5m08 and hp24m2sw. Placing your
mouse pointer over this trunk line shows you that two ports on each
device are aggregated into a trunk line.
Figure 9-2 Viewing Port Aggregation from a Neighbor View
In Figure 9-2 the status color of is 4kfcc5lc5m08 is yellow. That

indicates the device status is marginal.
Chapter 9 267
Figure 9-3 shows that by placing your mouse pointer over the port on
4kfcc5lc5m08 that connects to hp24m2sw, you can obtain more
information about the problem. Board 3 port 23 on 4kfcc5lc5m08 either
is disabled and must be enabled, or the port is physically disconnected
from the network and must be reconnected.
Figure 9-3 Viewing Additional Port Information from a Neighbor View
Using the VLAN View to Diagnose Network Problems

The following scenario gives an example of using Extended Topology
information to diagnose a network problem.
Suppose you saw the two alarms in Example 9-4 on page 269 in your
NNM Alarm Browser. It seems to indicate a traffic problem with your
network.
268 Chapter 9
To investigate, you could open two NNM Neighbor views by highlighting

each of these alarms in the Alarm Browser and using the
Actions:Views->Neighbor menu.
Figure 9-4 The Threshold Exceeded Alarms to Investigate
Figure 9-5 shows two Neighbor views. Notice the port information
displayed in each view when the mouse pointer is placed over the port
icons on either hp24m1sw or 212swtch. This shows you that ntctst20 is
connected to hp24m1sw board 1 port 2 and that vanguard is connected to
212swtch board 1 port 1.
Figure 9-5 Viewing the Switched Ports
Chapter 9 269
You recognize ntctst20 and vanguard as two test machines from an

isolated test environment that generates lots of traffic. Your records
show that you configured devices in this test environment to participate
in VLAN 10 and assigned ntctst20 and vanguard to ports on cisco0.
Someone apparently disconnected them from cisco0 and reconnected
vanguard and ntctst20 to other switches.
You could open a VLAN view from Home Base to see if any ports on
212swtch and hp24m1sw are participating in VLAN 10 (see Figure 9-6 on
page 271). You notice that neither 212swtch or hp24m1sw have ports
participating in VLAN 10. If there were a lot of VLANs in this view, you
could use the View:Find command to search for VLAN 10.
Figure 9-6 shows the ports from each switch that participate in a
specified VLAN. You could use this view to identify all of the ports
participating in VLAN 10. You could then select new ports for both
ntctst20 and vanguard and move these devices to remedy the traffic
problem.
NOTE Some VLAN views could show duplicate VLAN names. Extended
Topology distinguishes between VLANs which have identical names but
which reside on separate broadcast domains. See the HP OpenView web
online help for more information.
270 Chapter 9
Figure 9-6 Viewing VLANs with the VLANs View
Chapter 9 271
Launching Specific Views or URLs from Alarms
Launching Specific Views or URLs from

Alarms
You can configure Extended Topology to access a specific web location
from an event in the Alarm Browser. You can configure up to 50 URLs in
the xnmeventsExt.conf file for the Actions:Views menu. You can
already access Extended Topology views from Alarm Browser events,
however these new URLs can be any other URL that you prefer. NNM
and Extended Topology views are available from NNM’s Tools menu or
from Home Base.
To configure an alarm to launch a specific URL, edit the following file:
• Windows: %OV_CONF%\%LANG%\xnmeventsExt.conf
• UNIX: $OV_CONF/$LANG/xnmeventsExt.conf
Editing instructions are included in the file.
After you modify xnmeventsExt.conf, do the following for the changes
to take effect:
1. Close the NNM Alarm Browser.

2. Stop the ovalarmsrv process:
• As Administrator or root, run the following command:
— Windows: %OV_BIN%\ovstop ovalarmsrv

— UNIX: $OV_BIN/ovstop ovalarmsrv
3. Start the ovalarmsrv process:
• As Administrator or root, run the following command:
— Windows: %OV_BIN%\ovstart ovalarmsrv

— UNIX: $OV_BIN/ovstart ovalarmsrv
4. Run the following command to restart the NNM Alarm Browser:
• Windows: %OV_BIN%\xnmevents
• UNIX: $OV_BIN/xnmevents
5. Restart any web-based Alarm Browsers to view the new menu items.
272 Chapter 9
Launching Specific Views or URLs from Alarms
6. Refresh any Home Base views you have open.

7. Use the Fault:Alarms menu item to open the Alarm Browser. The
Actions:Views menu in the Alarm Browser should contain the new
menu items.
Chapter 9 273
Calculating Detailed Layer 2 and Layer 3 Information for ECS
Calculating Detailed Layer 2 and Layer 3

Information for ECS
Extended Topology calculates layer 2 and layer 3 network paths between
the Extended Topology management station and each managed device.
This information is used by the netmon process, ECS, and the
ConnectorDown correlation to provide better layer 2 and layer 3
diagnostic information in node down situations.
274 Chapter 9
10 Maintaining Extended Topology
Chapter 10 275
Maintaining Extended Topology

To maintain your Extended Topology application, you may need to
perform one or more of the following tasks.
Checking for Extended Topology Patch Releases

Check the OpenView web site for the latest patch releases or support
updates. You can find a link to the latest Extended Topology patches at:
http://www.openview.hp.com/services.
Backing Up Extended Topology Information

Configuration files for Extended Topology reside in the following
directory:
• Windows: %OV_CONF%\nnmet\
• UNIX: $OV_CONF/nnmet
Database files for Extended Topology reside in the following directory:
• Windows: %OV_DB%\nnmet\
• UNIX: $OV_DB/nnmet
You can use the ovbackup.ovpl command to back up these files. See
Managing Your Network with HP OpenView Network Node Manager for
more information.
Obtaining Supported Device Information

Extended Topology collects device information from specific MIBs
contained in discovered devices and uses this information to display
Dynamic Views.
To obtain a list of devices, MIBs, and connectivity information that
Extended Topology supports, point your browser to:
http://www.openview.hp.com/go?id=nnmet&page=1.
This information will help you understand if Extended Topology collects
device information from new device models you deploy.
276 Chapter 10
Troubleshooting Extended Topology Discovery

Discovery can take several hours to complete. This length of time
depends on network size, network traffic, the processing power of the
NNM management station, and how you configure your discovery zones.
If discovery takes longer that normal to complete and you use zones in
your discovery process, use the [Test Zone Configuration] button to
test your zones. This tests your configuration and may make
recommendations that might improve your discovery.
If you suspect you are having problems with Extended Topology
discovery, you can view discovery status details by running the following
command:
• Windows: %OV_BIN%\ovstatus -v ovet_disco

• UNIX: $OV_BIN/ovstatus -v ovet_disco
Executing the ovstatus -v ovet_disco Command

For an example of the output from ovstatus -v ovet_disco during
discovery, see Example 10-1.
Example 10-1 Output of ovstatus -v ovet_disco During Discovery

object manager name: ovet_disco
state: RUNNING
PID: 28818
last message: Discovery started: Mon Nov 19 10:44:16 2002.
exit status: -
additional info:
The additional info field in Example 10-1 may report different
messages, such as:
Discovery started: time discovery started.
Entered Phase 1: Access testing quantity of nodes for ET.discovery (quantity of
nodes completed).
Entered Phase 1: Collecting device attributes from node quantity nodes in zone
IPV6.
Entered Phase 1: Collecting device attributes from node quantity nodes in zone
DEFAULT.
Entered Phase 1: Collecting device attributes from qnode uantity nodes in zone
zone number.
Chapter 10 277
Entered Phase 2: Collecting environment attributes from node quantity nodes in

zone IPV6.
zone DEFAULT.
zone zone number.
Entered Phase 3: Collecting connectivity data from node quantity nodes in zone
IPV6.
DEFAULT.
zone number.
Final collection phase completed. Now calculating connectivity for node quantity
nodes in zone IPV6.
nodes in zone DEFAULT.
nodes in zone zone number.
Connectivity calculation completed. Now creating topology for node quantity
nodes in zone IPV6.
nodes in zone DEFAULT.
nodes in zone zone number.
Discovery completed and processes stopped until next discovery: time discovery
completed.
Awaiting next discovery cycle.
When Extended Topology has finished discovery, the message in the
additional info field is Awaiting next discovery cycle, and only
that message is displayed until the next discovery cycle begins.
If you never see the Awaiting next discovery cycle message or if the
output of the ovstatus -v ovet_disco command differs from the
example above, you may want to restart Extended Topology discovery by
running the following command:
278 Chapter 10
Troubleshooting Additional Problems

Some of the last messages from the ovstatus -v ovet_disco
command could point to or duplicate entity errors or database errors. To
resolve these errors use the following information.
Resolving Duplicate Entity Errors If you see the following error

message, you may have entered incorrect HSRP information.
Duplicate entity error - before restarting discovery, consult Using Extended
Topology manual for trouble-shooting steps (HSRP Virtual IP Address)
Notice that the IP address at the end of the message is the HSRP virtual
IP address. You need to modify some HSRP configuration information.
See “Running HSRP Discovery” on page 257 for more information.
You may see a similar error message if you took either of the following
actions:
• You manually moved devices between or among zones, and then only
initiated the discovery of a single zone. To remedy this you need to
initiate a full discovery. See “Manually Configuring Zones” on
• You chose to complete an automatic zone configuration, and then
only initiated the discovery of a single zone. To remedy this you need
to initiate a full discovery. See “Automatic Zone Configuration” on
Resolving Database Errors If you see the following error message,

you have encountered some database problems that you may be able to
resolve.
Database error - before restarting discovery, consult Using Extended Topology
manual for trouble-shooting steps.
To resolve these problems, use the following steps:
1. Check to see if any of your system disks are full. If they are, you need
to free up (or add) some disk space.
2. Run the ovstatus ovdbcheck command and follow the displayed
instructions.
3. If these steps do not resolve the issue, you need to contact support.
You can find support information at http://openview.hp.com.
Chapter 10 279
Troubleshooting Extended Topology Views

You may encounter problems with views, such as the view not appearing
or the view not presenting all the expected data. See the Troubleshooting
Views section of the HP OpenView web online help for more information
about Troubleshooting Extended Topology views.
In certain circumstances where device information is limited, Extended
Topology may not accurately discover and model every connection in a
network. As a result, you may see no connections where you know
connections exists, or connections indicated where you know none exist.
You can use the Connection Editor functionality to correct this
information. See Appendix C, “Modifying Connections with the
Connection Editor,” on page 301 for more information.
280 Chapter 10
A Common Zone Configuration
Examples
Appendix A 281
Common Zone Configuration Examples
Network designers deploy various enterprise network designs to meet

their customers' requirements.The network designs described in this
appendix contain patterns that can be used to plan and configure the
Extended Topology discovery.
282 Appendix A
Campus Environment Scenario

Suppose you are managing the modern campus environment shown in
Figure A-1, “A Typical Campus Environment,”
Figure A-1 A Typical Campus Environment
Each switch block fromFigure A-1connects to the core block as shown in

Figure A-2 on page 284
Appendix A 283
Figure A-2 Core Block
NOTE The VLAN numbering shown in Figure A-2 is only a sample. The access
switches can, and probably will, have overlapping VLAN IDs. Assume
that you create DNS names for devices based upon geography for this
enterprise network (for example switch.bldg4.atlanta.company.com).
Figure A-2, “Core Block,” shows a redundant network to better
demonstrate how to configure Extended Topology zones for more efficient
and accurate discovery.
The rest of this appendix discusses zone discovery configurations that

refer to the network models shown inFigure A-1. You can interchange
the terms buildings, locations, or sites depending on the size of your
company.
284 Appendix A
General guidelines
The following strategies can be replicated for all campuses of the

enterprise. The following discussion does not go into any detail for WAN
block designs, since Extended Topology is designed to discover layer 2
and other protocol information. It does not discover WAN information.
General guidelines
Do not separate the following equipment into different zones:
1. Directly connected switches

2. Switches connected to routers
3. Switches in the same VLAN (that is, having the same globally VLAN
names or IDs)
Separating the above equipment into separate zones will result in
inaccurate discoveries. You can place a router in multiple zones to avoid
separating it.
Extended Topology discovers router-to-router connectivity information
only if routers support CDP. If your routers don’t support CDP, it doesn’t
matter how you divide them up, as Extended Topology cannot obtain
connectivity information from routers not supporting CDP.
If you don't need to view router connectivity within the Extended
Topology neighbor view, configure the core routers in as few zones as
possible.
If the network size in each building is too small, combine the networks of
two or more buildings to get a bigger zone. Add the core routers for each
building into that zone.
Based on OpenView tests, you may want to start with zones of 200 nodes
or less. The OpenView tests discovered devices with port densities of 24,
and were run on HP C3000 and Sun Ultra 60 workstations with 512 MB
of RAM. However, in some environments successful discoveries can have
up to four times that many devices in a zone. You might want to
experiment to decide what zone size works best for you, based on the
following parameters:
• The port densities of the devices you plan to discover.
Appendix A 285
Specific guidelines
• Extended Topology system memory size.

• Extended Topology system CPU size.
• The number of VLANs your network contains.
• Other resource settings.
Remember to use the [Test Zone Configuration] button to test your
zones.
Specific guidelines
These guidelines are for some sample network types that may be
commonly deployed.
Possibility 1: Core Devices are Routers

• The network contains core devices that are all routers.
• Campus buildings/sites are mostly switched, with router interfaces
placed between switch blocks or VLANs.
286 Appendix A
Specific guidelines
Figure A-3 Core is Routed
Zone 1 Routers
Core Core
Router Router
Switches
Switches
Servers/PCs
Servers/PCs
Zone 2 Zone 3
Suggested zone configuration
• To configure discovery for the switch-to-switch and switch-to-router

connectivity, do the following:
Refer to Figure A-3, “Core is Routed,” for this discussion. Put all of
the access switches, distribution switches/routers, and core router(s)
that service the building into zone 1 using the name wildcard method
for defining a zone. Using this method, you can create a zone for
every building in your campus, provided it meets the above criteria.
• To configure discovery for the router-to-router connectivity, do the
following:
Appendix A 287
Specific guidelines
Refer to Figure A-3, “Core is Routed,” for this discussion. Configure

the core routers into one zone by themselves. Splitting the core
routers into multiple zones may increase management traffic from
bordering routers to the core routers for each zone you add the core
routers to. You should split large core routers into a few zones to
speed up discovery. Doing this will speed up discovery at the cost of
higher management traffic. It is a design choice that you need to
make at zone configuration time.
288 Appendix A
Specific guidelines
Possibility 2: Core Devices are Switches

The network contains core devices that are all switches.
Campus buildings or sites are mostly switched, with router interfaces
placed between switch blocks and/or VLANs.
Figure A-4 Core is Switched: Using Two Zones

Zone 1 Switches
Core Core
Router Router
Switches
Switches
Servers/PCs Servers/PCs
Zone 2
Appendix A 289
Specific guidelines
Figure A-5 Core is switched: Using One Zone
Core Core
Router Router
Switches
Switches
Switches
Servers/PCs Servers/PCs
Zone 1
Suggested zone configuration
• Refer to Figure A-4, “Core is Switched: Using Two Zones,”and

Figure A-5, “Core is switched: Using One Zone,”for this discussion.
To configure discovery for switch-to-switch, and switch-to-router
connectivity, do the following:
Follow the same specific guidelines as defined in Possibility 1 for
getting switch-to-switch, and switch-to-router connectivity in the
switch blocks of various buildings.
Also, since the core devices are switches now, you should place all of
the core devices and the corresponding distribution and WAN routers
in the same zone for that building.
290 Appendix A
Specific guidelines
If your entire network is very small you can place all of your devices
in one zone as shown in Figure A-5 on page 290. However, if
Extended Topology recommended that you use multiple zones when
you ran setupExtTopo.ovpl,use multiple zones.
If Zone 2 in Figure A-4 on page 289 exceeds a reasonable zone size,
break up the zone into multiple zones.
• To configure discovery for router-to-router connectivity, do the
following:
Since the network type is mostly switched except for the distribution
and WAN layers, and the distribution layer routers are connected to
switches, the only router connectivity that is left to be discovered is
WAN to WAN router connectivity. WAN routers typically won’t run
CDP, hence you can break up the WAN routers as you wish.
Appendix A 291
Specific guidelines
292 Appendix A
B Successfully Deploying
Extended Topology: Practical
Deployment Tips
Appendix B 293
Successfully Deploying Extended Topology: Practical Deployment Tips
Extended Topology Deployment Tips

OpenView engineers compiled some simple, yet important Extended
Topology deployment tips. For better understanding, read through the
Extended Topology manual prior to reviewing the following information.
It is recommended that you read through this entire list of deployment
tips prior to running your first Extended Topology discovery.
Prediscovery Tips
Below is a list of activities that you may want to complete prior to
running your first Extended Topology discovery.
• It is much easier to discover devices and connectivity on a healthy

network. The support directory contains tools to help you understand
the health of your NNM installation. Scripts such as checkDNS.ovpl
and resolveNames.ovpl can be extremely helpful. You can find
support tools in the following (support) directory:
— Windows:%OV_MAIN_PATH%\support
— UNIX: $OV_MAIN_PATH/support
• You should research whether Extended Topology can discover
information about the devices on your network. You can do this by
viewing the device list or the supported MIBs for a family of devices
at the following URL:
http://www.openview.hp.com/go?id=nnmet&page=1.
If your network contains unsupported devices, you may want to run
your first Extended Topology discovery without these nodes. You can
use the bridge.noDiscover file to stop Extended Topology from
discovering device information about these nodes. See “Limiting
Extended Topology Discovery” on page 32, or the bridge.NoDiscover
reference page in NNM’s online help (or the UNIX manpage) for
more information.
NOTE If you choose to run your discovery and include these nodes, these
unsupported devices may cause problems.
294 Appendix B
• You should not allow Extended Topology to discover device

information about managed hubs. You should enter any managed
hubs in the bridge.noDiscover file. This file doesn’t support
sysObjectID filters so you will need to work with NNM’s
ovtopodump tool to get the node list. See the ovtopodump reference
page in NNM’s online help (or the UNIX manpage) for more
information.
• It is a good idea to start your first Extended Topology using only a
small quantity (10-20 nodes) of directly connected nodes. It is best to
target networking nodes such as switches and routers. You could
include a pair of routers that support HSRP routers too. You should
know their topology so you can validate the results. Another
advantage of a small test run is that you don’t need to worry about
zone definitions.
• If you want to avoid using complex Extended Topology filters, you
can use the following approach to create a small NNM database
containing only a few nodes:
1. Use the loadhosts tool to build a small database. See the

loadhosts reference page in NNM’s online help (or the UNIX
2. After loading nodes with the loadhosts tool, run an
nmdemandpoll nodename on each node to speed up NNM’s
configuration poll. See the nmdemandpoll reference page in
NNM’s online help (or the UNIX manpage) for more information.
3. After you complete loading these nodes, run, as root or
Administrator, the setupExtTopo.ovpl script to configure
Extended Topology and start your discovery. See the
setupExtTopo.ovpl reference page in NNM’s online help (or the
• Before running your first Extended Topology discovery, you need to
understand your network topology. You should understand the
following characteristics of you network.
— What are all of the complexities of your network?

— Does your network contain a lot of VLANs?
— Does your network contain a lot of redundant paths?
— Does your network contain HSRP routers?
Appendix B 295
You’ll be more confident in the Extended Topology discovery results if

you can compare them to the actual topology.
• There are several protocols that can help Extended Topology
discovery layer 2 more accurately. For example, if the Cisco devices
on your network support CDP and the Extreme Network devices on
your network support EDP, then your layer 2 connectivity should be
much more accurate.
• Networks that have low traffic levels are much more difficult to
discover. This is due to switches in this low traffic area having empty
Forwarding Database (FDB) Tables.
To remedy this, run your Extended Topology discovery when the
network is active. If you must run your Extended Topology discovery
during low traffic times, telnet onto the switches shortly before
Extended Topology discovery and ping the adjacent switches. This
will fill the FDB tables. If your switches support CDP or EDP, this
may not be necessary.
• If you run OSPF in your network, and you have purchased and
installed a license for the Advanced Routing SPI, then you need to
run an OSPF discovery separately from a normal Extended Topology
discovery. It is important to understand that Extended Topology only
discovers OSPF nodes that are currently managed by Extended
Topology.
You will probably want to run an OSPF discovery against your large
network, as running this discovery with only a small test network
will probably not be successful. A nice debug approach is to run
ospfdis.ovpl dbg=1. See “Discovering OSPF Information” on
Discovery Tips
Below is a list of activities that you should complete in order to
successfully run your first Extended Topology discovery.
• After you have used the relevant information in the Prediscovery

Tips section, you are ready to run your first Extended Topology
discovery. If you have not enabled Extended Topology, run, as root or
Administrator, the setupExtTopo.ovpl script. Answer yes to
questions about enabling the appropriate agents. After this script
completes, an Extended Topology discovery begins.
296 Appendix B
If you enabled Extended Topology earlier, then, as root or

Administrator, run the etrestart.ovpl script to run a new
Extended Topology discovery. See the etrestart.ovpl reference page in
NNM’s online help (or the UNIX manpage) for more information.
TIP You can use the -verbose option with the etrestart.ovpl script to
show process status messages.
• To make sure that the entries in your bridge.noDiscover file are

working correctly, monitor the following file:
— Windows: %OV_DB%\nnmet\hosts.nnm
— UNIX: $OV_DB/nnmet/hosts.nnm
This file contains a list of all the nodes from which Extended
Topology will discover information. This file is updated at the
beginning of each Extended Topology discovery.
As an example of how to monitor the hosts.nnm file, suppose that
you expected your filters to target an Extended Topology discovery of
only ten nodes. If the hosts.nnm file contains more than ten nodes,
then something is wrong with your filters and should be corrected.
• It is a good idea to monitor the Discovery progress by launching the
Home Base page from a browser. To do this, open the Extended
Topology Configuration GUI using the NNM Options: Extended
Topology Configuration menu or select the Discovery Status
tab from Home Base. If you are having problems getting Home Base
to come up, try the following:
— Make sure you have the right JPI installed.

— Launch Home Base from another computer. If this works, look for
differences in your browser settings.
— Proxy Servers can cause some problems for Home Base. Try
running without the Proxy Server and see if that helps.
— Try clearing the cache on your browser and clearing the cache in
your JPI (done via the control panel in Windows).
— Another common problem you could encounter is an improperly
configured domain name resolution (DNS) server. The browser
must be able to resolve the DNS name of the Extended Topology
Appendix B 297
server. This problem usually manifests itself with Extended

Topology displaying a blue box without loading the Dynamic
Views applet. To test DNS, from the Extended Topology system,
run the following script:
— Windows:
%OV_MAIN_PATH%\support\NM\ovgethostbyname.ovpl
— UNIX:
$OV_MAIN_PATH/support/NM/ovgethostbyname.ovpl
This script should return a fully qualified host name (like
foo.hp.com). If it returns a short name, you should change
your DNS server configuration or your hosts file on the
Extended Topology server to remedy this problem. After your
name resolution is working properly, you need to, as root or
Administrator, re-run the setupExtTopo.ovpl script.
Post Discovery Tips

Below is a list of activities that you will want to complete after running
your first Extended Topology discovery.
• After discovery completes, go to Home Base and select the

Discovery Status tab. From there, select [View Topology
Summary] and review the results.
1. Review the number of Layer 2 and VLAN connections. Were any

found during the discovery? If not, then something went wrong
during the discovery. Extended Topology needs SNMP access to
devices in order to complete an accurate discovery. You should
check for nodes that didn’t respond to SNMP by using the
following tool:
— Windows:
%OV_MAIN_PATH%\support\NM\ETsNoSnmpNodes.ovpl
— UNIX: $OV_MAIN_PATH/support/NM/ETsNoSnmpNodes.ovpl
2. You should fix any SNMP access problems using NNM’s SNMP
Configuration user interface (UI). You can access the SNMP
Configuration UI using NNM’s Options: SNMP Configuration
menu. Extended Topology will apply any changes you make to its
next discovery.
298 Appendix B
• Another useful tool to examine the results of the discovery is listed

below:
— Windows:
%OV_MAIN_PATH%\support\NM\ovet_topoobjcount.ovpl -al
— UNIX: $OV_MAIN_PATH/support/NM/ovet_topoobjcount.ovpl
-al
• Use the following techniques to launch some of the other views to see
how they look.
— From Home Base, try running a neighbor view from one of your
switches.
— If you are happy with your views and want to try a full discovery,
now is a good time to have Extended Topology discover your
entire network.
— If you would rather take a more conservative second step when
setting up a more extensive Extended Topology discovery,
consider creating a medium size discovery with a few hundred
nodes.To do this, you would remove specific switches and routers
from the bridge.noDiscover file or you could modify some of
your zone definitions. Go through the same analysis previously
described to validate your discovered devices as you did in prior
steps. Make sure you don’t leave out critical network devices and
end up with connectivity gaps.
connections exists, or connections indicated where you know none
exist.You can use the Connection Editor functionality to correct this
information. See Appendix C, “Modifying Connections with the
Connection Editor,” on page 301 for more information.
Appendix B 299
300 Appendix B
C Modifying Connections with the
Connection Editor
Appendix C 301
Modifying Connections with the Connection Editor
An Overview of the Connection Editor Functionality
An Overview of the Connection Editor

Functionality
connections exist, or connections indicated where you know none exist.
NOTE Be careful in your assessment of connection accuracy. Extended Topology

frequently surprises network administrators by showing that the
network’s actual topology differs from expectations. Before using the
facilities described here, make sure that your changes reflect the true
topology, and not merely what is believed about it.
To modify Extended Topology’s connection information, you first create

the connectionEdits file, and then add and delete specific connections
by making entries in that file. This appendix describes the procedure in
detail.
IMPORTANT Some device configuration activities cause SNMP agents to renumber

the interfaces of some Ethernet switches and routers. These activities
include the following actions:
• Moving a board from one slot to another

• Removing a board
• Adding a new board
• Removing the supervisor board in a dual supervisor board system
• Power cycling a switch or router
You should not use the connectionEdits file to modify the discovered
connections for these nodes. If you do, you will have to modify the entries
for that device in the connectionEdits file each time the device’s
interfaces are renumbered.
302 Appendix C
An Overview of the Connection Editor Functionality
At the end of its work, the ovet_disco process uses the

connectionEdits file to modify the discovered topology data. You can
also apply connection edits to the data from a previous discovery using
the ovet_topoconnedit.ovpl script.
Appendix C 303
Using the Connection Editor

Extended Topology uses the ovet_disco process to collect connectivity
information from network infrastructure devices (connectors) and other
non-connector devices (end nodes) such as servers, workstations, or PCs.
This information includes device attributes and their relationships to
other devices in the network.
Extended Topology uses this information to show you how your devices
interconnect. You can amend or remove device connections during the
course of a discovery, or after a discovery has completed by creating and
modifying the following file:
• Windows: %OV_DB%\nnmet\connectionEdits
• UNIX: $OV_DB/nnmet/connectionEdits
The connectionEdits File Syntax

You can describe connections in the connectionEdits file using the
names of interfaces located on connectors and end nodes. These
interfaces must already exist in the extended topology, or must be
discovered by the ovet_disco process.
You can add interfaces to the connectionEdits file using the following
form:
fully-qualified-node-name[ 0[ ifIndex ] ]
An example of this is show below:
coreswitch3.corp.net[ 0[ 50 ] ]
Using OQL Inserts

Interface specifications are combined into SQL statements, or inserts.
More specifically, these inserts are OQL statements, which are a subset
of SQL statements. These OQL statements have extensions for
controlling extended topology operations and are used internally during
Extended Topology discovery to create or delete connection
representations. The following example shows the format of an OQL
insert statement in the connectionEdits file:
304 Appendix C
insert into disco.connectionEdits (m_Name, m_NbrName, m_Command) values

(‘interface1-name’, ‘interface2-name’, command);
Below are some hints on how to add inserts to the connectionEdits file:
• The quotes and semicolon are required.

• Each insert statement must be on a single line.
• The order of the interfaces in the OQL statement is not important.
Extended Topology checks the connectivity information from both
devices referenced in the insert statement.
• You can use one of the following entries as a command parameter:
— 0 - This tells Extended Topology to ignore this entry. This is

helpful if you want to place comments in your entries.
— 1 - This tells Extended Topology to add this connection.
— 2 - This tells Extended Topology to delete this connection.
OQL Insert Examples

Below are some examples of how you might use the connectionEdits file
to meet your specific needs.
• Suppose you want to comment on the connection between two

connected devices, SwitchA and SwitchB, but do not want Extended
Topology to take any action. In this example, both devices use
ifIndex 91. You could add the following line to the
connectionEdits file:
(‘SwitchA.hp.com[ 0 [ 91 ] ]’, ‘SwitchB.hp.com[ 0 [ 91 ] ]’, 0);
• Suppose you want to configure Extended Topology to show the
connection between two connected devices, SwitchA and SwitchB. In
this example, both devices use ifIndex 91. You could add the
following line to the connectionEdits file:
• Suppose you wanted to remove an invalid connection between two
devices, SwitchA and SwitchB. In this example, both devices use
ifIndex 91.You could add the following line to the
connectionEdits file:
Appendix C 305

Helpful Tools
There are several tools that can help you create and modify the
connectionEdits file. These tools are located in the following
directories:
• Windows:%OV_MAIN_PATH%\support\NM
• UNIX: $OV_MAIN_PATH/support/NM
NOTE The tools in the above directory are made available for HP support
engineers, and are not designed or tested for end-users. They are
described here because you may find them helpful, but Hewlett-Packard
offers no support for them.
Identifying the ifIndex

Switch vendors use various schemes to map physical ports to ifIndex
values. Some vendors number their ports sequentially starting at 1 and
have a one-to-one mapping of port numbers to ifIndex values. Some
vendors label the port numbers based on its position on the board on
which it is located. For example, 3/1 would represent board 3, port 1,
and B2 would represent board B, port 2. Then the vendors use a scheme
to map the board/port combinations to ifIndex values.
Extended Topology discovers these board/port-to-ifIndex relationships.
In many cases, switches also incorporate the board and port information
into the ifDescr or ifName objects reported by the SNMP agent. To see
these relationships, you can use the following command:
ovet_topoquery getNodeByName node-name
Look for the Description in the NMInterface sections of the output or the
IfName, BoardNo and PortNum fields in the Interface Property
sections of the output. Use the IfIndex or EntityName field of that
output to determine the appropriate ifIndex value to use in the
connectionEdits file.
306 Appendix C
NOTE The ovet_topoquery command resides in the following directory:
• Windows: %OV_MAIN_PATH%\support\NM
• UNIX: $OV_MAIN_PATH/support/NM
Routers and end-nodes typically have IP addresses associated with their

connected interfaces. NNM and Extended Topology use the value
supplied in the SNMP MIB table ipaddrTable to link IP addresses to
ifIndex. You can use the following command to see the
IP-address-to-ifIndex association for discovered interfaces:
ovtopodump -l <node-name>
Using Support Tools to Assist You

There are several support tools you can use when creating and adding
insert statements into the connectionEdits file. You must run these
tools as Administrator or root.
• ovet_topoconndump.ovpl script
You can use the ovet_topoconndump.ovpl script prior to adding
insert statements to the connectionEdits file. When used without
any parameters, it will dump all the layer 2 connections currently in
the extended topology in the form of OQL insert statements into the
disco.connectionEdits table.
You can also use the -node parameter with the
ovet_topoconndump.ovpl script to display the layer 2 connections
associated with a specified node. The syntax would look like this:
ovet_topoconndump.ovpl-node fully-qualified-node-name
Below are some examples of how to use the
ovet_topoconndump.ovpl script:
— If you run the ovet_topoconndump.ovpl script with no

arguments, Extended Topology displays all layer 2 connections in
the extended topology.
Appendix C 307
— If you run ovet_topoconndump -node hp4k1sw.hp.com,

Extended Topology displays the layer 2 connections associated
with hp4k1sw.hp.com. You can capture the text from this display
and use it as a starting point for creating your connectionEdits
file. The output would look something like this:
(‘hp4k1sw.hp.com[ 0 [ 91 ] ]’, ‘hp4k2sw.hp.com[ 0 [ 91 ] ]’, 0);
(‘hp4k1sw.hp.com[ 0 [ 81 ] ]’, ‘hp212sw.hp.com[ 0 [ 18 ] ]’, 0);
(‘cisco5500.hp.com[ 0 [ 6 ] ]’, ‘hp4k1sw.hp.com[ 0 [ 17 ] ]’, 0);
NOTE Notice that Extended Topology includes the number 0 (the first
character to the right of the left square bracket following each
fully qualified node name) in each entry line item. Do not remove
or modify the number 0 when adding inserts into your
connectionEdits file. The O character is reserved for future use
and is not currently used.
• ovet_topoconnedit.ovpl script
You can use the ovet_topoconnedit.ovpl script to make changes in an
existing extended topology without running a discovery. The
ovet_topoconnedit.ovpl script reads the connectionEdits file and
updates the extended topology database. Extended Topology silently
ignores invalid or duplicate entries contained within the
You must stop and restart the embedded OpenView application server,
ovas, to see the results of the applied changes. You should also restart
the ovet_poll process in order to inform it of any interface connectivity
changes from the connectionEdits file:
1. As Administrator or root, type ovstop ovas.

2. Press Return or Enter.
3. As Administrator or root, type ovstop ovet_poll.
308 Appendix C
5. As Administrator or root, type ovstart ovas.

7. As Administrator or root, type ovstart ovet_poll.
Practical Examples
The following examples depict some actual connectivity problems and
potential solutions using the connectionEdits file.
Example C-1 Making Map Modifications

Refer to Figure C-1 on page 310 for this example. Suppose Extended
Topology "discovers" a connection between SwitchA and SwitchB that
doesn’t actually exist. For a number of reasons, including accurate
root-cause analysis, you want to remove that connection from topology.
You can use the following procedure to remove the connection between
SwitchA to SwitchB from future discoveries:

ovet_topoconndump.ovpl -node hp4k1sw.hp.com
Running the above command results in the following display:
insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values
(‘SwitchA.hp.com[ 0 [ 1 ] ]’,’hp4k1sw.hp.com[ 0 [ 56 ] ]’,0);
(‘SwitchB.hp.com[ 0 [ 91 ] ]’,’hp4k1sw.hp.com[ 0 [ 91 ] ]’,0);
(‘hp4k1sw.hp.com[ 0 [ 91 ] ]’,’hp4k2sw.hp.com[ 0 [ 91 ] ]’,0);
Notice that the above display that describes a connection between
ifIndex 56 of hp4k1sw to ifIndex 1 of SwitchA.
2. Edit the connectionEdits file and add the following text:
(‘SwitchA.hp.com[ 0 [ 1 ] ]’,’hp4k1sw.hp.com[ 0 [ 56 ] ]’,2);
Appendix C 309
Notice that the value for the m_Command field of the insert
statement is 2 for delete the connection.
Figure C-1 Making Map Modifications
Example C-2 Adding Connections that are Missing

Suppose, in Figure C-1, that Extended Topology failed to discover an
actual connection between SwitchB and SwitchA.
You can use the following steps to add this connection to future
discoveries:
1. Determine which ifIndex value of SwitchB to use for the

connection. For this example, assume that port B2 is used on
SwitchB. As Administrator or root, run the following command:
ovet_topoquery getNodeByName SwitchB.hp.com
:
:
+++++++++++++++++ NMInterface ++++++++++++++
310 Appendix C
ObjID:2d037786-f5c1-71d7-11b6-0f0276230000
NNMObjID:764
EntityName:SwitchB.hp.com[ 0 [ 42 ] ]
Description:B2
:
:
==========Interface Property===============
VPI:0
VCI:0
BoardNo:B
PortNum:2
AuxPortNum:42
IfIndex:42
IfName:B2
IfAlias:-
IfType:6
PhysicalAddress:00:30:C1:EF:13:D7
:
:
By looking at the information listed in the above output, you
determine that you should use ifIndex value 42 for SwitchB.
2. Determine which ifIndex value of SwitchA to use for the
connection. As Administrator or root, run the following command:
ovet_topoquery getNodeByName SwitchA.hp.com
+++++++++++++++++ NMInterface ++++++++++++++
ObjID:31ebc672-f5c1-71d7-11b6-0f0276230000
NNMObjID:808
EntityName:SwitchA.hp.com[ 0 [ 2 ] ]
Description:2
:
:
==========Interface Property===============
VPI:0
VCI:0
BoardNo:
PortNum:2
AuxPortNum:2
IfIndex:2
IfName:2
:
:
Appendix C 311
3. For this example, assume that port 2 is the actual port number used
on SwitchA as displayed in the output from the previous step. Edit
the connectionEdits file and add the following statement:
(‘SwitchA.hp.com[ 0 [ 2 ] ]’,’SwitchB.hp.com[ 0 [ 42 ] ]’,1);
Notice that the value for the m_Command field of the insert statement
is 1 for add.
Example C-3 Adding Connections for Unsupported Devices

Extended Topology does not yet support all network devices. When an
unsupported device plays a key role in connectivity, you may see a
"fully-meshed" or "false mesh" layout that does not reflect reality.
For example, the layout shown in Figure C-2 on page 313 may be due to
an unsupported switch that physically links each of the routers in a star
configuration. Although the connectivity it provides was discovered, the
device itself was not, so it is missing from the layout. You will want to use
the connectionEdits file to create a correct topology model.
In Figure C-2 on page 313, the false mesh may be due to an unsupported
switch that, although it is physically linking each of the routers, it is
missing from the center of the web on your Dynamic View.
312 Appendix C
Figure C-2 A False Mesh of Connections
In this situation, each of the connections on devices around the edge will
be connected to other devices in the false mesh by the same interface.
This means that the ifIndex will be the same as the other devices in the
mesh. To remove the false mesh, you may have to insert a delete
connection entry to the connectionEdits file for each of these
connections. You will also have to insert an add connection entry in the
connectionEdits file for each of the actual connections from the
unsupported device to the switch. Use the following procedure to fix the
problem in this example:
1. To create the delete connection entries, find the ifIndex value for
each device in the false mesh. This is most easily done from a
Neighbor View by moving your mouse over each port icon and noting
the Interface Number field located in the popup. For the above
picture, this would yield entries such as:
Appendix C 313

(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’mcrouter81.hp.com[ 0 [ 4 ] ]’,2);
(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’c8kloop.hp.com[ 0 [ 1 ] ]’,2);
(‘mcrouter81.hp.com[ 0 [ 4 ] ]’,’c8kloop.hp.com[ 0 [ 1 ] ]’,2);
:
:
2. To create the add connection entries, find the ifIndex value for each
of the interfaces on the unsupported device. This could be done by
physically examining the device, by querying the appropriate SNMP
MIB which provides forwarding table information (perhaps using the
NNM MIB Application Builder tool), or by some other proprietary
means.
Once you obtain this connectivity information, create entries in the
connectionEdits file for each of the devices located at the edge of
the spider web. These entries describe their connections to the
unsupported device that is located in the middle of the false mesh.
This device is identified as mcswitch in the example below.
(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’mcswitch.hp.com[ 0 [ 21 ] ]’,1);
(‘c8kloop.hp.com[ 0 [ 1 ] ]’,’mcswitch.hp.com[ 0 [ 25 ] ]’,1);
314 Appendix C
An Extended Topology discovery using the above additions to the

connectionEdits file would result in the Neighbor View shown in
Figure C-3.
Figure C-3 Corrected Neighbor View
Other Limitations and Behaviors

• Interfaces described in the connectionEdits file must physically
exist. Extended Topology must be able to discover these interfaces.
• If you create a connection for an interface in the connectonEdits
file, that does not prevent Extended Topology from creating other
connections to that interface.
Appendix C 315
• If you used the ovet_topoconnedit.ovpl script to make changes to

the extended topology database and want to see the changes you
made to the connectionEdits file reflected in dynamic views, you
must restart the OpenView application server (ovas) and the Active
Problem Analyzer (referred to as APA or the ovet_poll process):
1. As Administrator or root, type ovstop ovas.

3. As Administrator or root, type ovstop ovet_poll.
5. As Administrator or root, type ovstart ovas.
7. As Administrator or root, type ovstart ovet_poll.
• To make sure the Dynamic Views contain all of your changes, you
should initiate a new discovery each time you make changes to the
NOTE A new discovery ensures that all extended topology data is consistent
with the changes introduced in the connectionEdit file.
316 Appendix C
D Controlling Log Files
All default logging for installed OpenView components is controlled by a

configuration file, log.cfg. This file sets the system-wide defaults for
common logging.
Appendix D 317
Controlling Log Files
Types of Log File
Types of Log File

There are two types of log file - binary and text. By default, all processes
write to binary log files. These are locale-neutral. Take, for example, a
binary file generated in a Japanese system. Using the ovlogdump tool
(see ovlogdump(1)), you would see Japanese messages. If you were to
take the same log file, install it on an English system, then, using the
ovlogdump tool, you would see English messages.
Text log files are locale-specific. Messages are written to the text files in
the language set by the local environment variable. Text logging can be
switched off or on (see “Switching Logging Off and On” on page 321).
318 Appendix D
Controlling the Size of Log Files

To prevent log files from growing excessively, log file rolling is used to
create multiple smaller files that can be archived or removed. You can
specify a maximum number of log files to be created and the maximum
size of each log file. Whenever a log entry causes a log file to exceed the
maximum size, the file is closed and a new file is opened, using the next
sequence number as part of its name.
For example, say you had a log file called system.txt. When that file is
full, the file is renamed to system.txt.001 and a new system.txt is
created. The next time, system.txt.001 is renamed to system.txt.002,
system.txt is renamed to system.txt.001, and a new system.txt is
created.
You control these settings by editing the logging configuration file,
log.cfg.
The file contains a keyword and value pair per line. There can be no
blanks, blank lines, or comments. The keywords are case-sensitive.
The keywords are:
BinSizeLimit=n
Sets the maximum size of binary log files to n bytes
before it rolls to the next file. Default is 10000.
BinFileLimit=n
Sets the maximum number of binary log files to
generate before throwing away log entries. Default is
10.
TextSizeLimit=n
Sets the maximum size of text log files to n bytes before
it rolls to the next file. Default is 10000.
TextFileLimit=n
Sets the maximum number of text log files to generate
before throwing away log entries. Default is 10.
Appendix D 319
The configuration and log files for MS Windows systems are stored in the
following locations indicated in Table D-1.
Table D-1 MS Windows Configuration and Log Files
Configuration file:
C:\Program Files\HP OpenView\Data\conf\xpl\log\log.cfg
Binary log files:
C:\Program Files\HP OpenView\Data\log
Text log files:
C:\Program Files\HP OpenView\Data\log
The configuration and log files for UNIX systems are stored in the
following locations indicated in Table D-2.
Table D-2 UNIX Configuration and Log Files
Configuration file:
/var/opt/OV/conf/xpl/log/log.cfg
Binary log files:
/var/opt/OV/log
Text log files:
/var/opt/OV/log
320 Appendix D
Switching Logging Off and On

You can switch logging off and on by changing the settings in the logging
configuration file, log.cfg.
The file contains a keyword and value pair per line. There can be no
blanks, blank lines, or comments. The keywords are case sensitive.
The keywords are:
TextLog=off|on
Switches locale-specific text logging off and on.
Switching this on causes the logging libraries to write a
locale-specific log in human-readable format. Default is
off.
OVLog=off|on
Switches binary logging off and on. Default is on.
WARNING Switching off this option will prevent any binary

logging for any component.
SysLog=off|on
Switches logging by syslog off and on.
NTLog=off|on
Switches logging by the Windows event log off and on.
It has no effect on UNIX systems. Default is off.
OVEvents=off|on
Switches message forwarding to the OpenView
Operations event system off or on. Default is on.
See Table D-1 and Table D-2 for more information about the location of
the configuration and log files on UNIX and MS Windows systems.
Appendix D 321
322 Appendix D
Glossary
A HSRP Hot Standby Routing Protocol. A

proprietary Cisco protocol that provides
ABR Area Border Router. A router with an backup to a router when it fails.
interface in more than one OSPF area.
I
Area OSPF divides contiguous networks
and hosts into a number of areas using Area ILMI Interim Local Management Interface.
Border Routers. An independent industry standard used for
configuring ATM interfaces.
ARP Address Resolution Protocol. A
protocol that maps IP addresses to Ethernet IPv4-Compatible Addresses Dual-stacked
addresses. nodes understand both IPv4 and IPv6
addresses and use IPv4-compatible
ATM Asynchronous Transfer Mode. A addresses to tunnel IPv6 packets through
high-speed connection-oriented switching IPv4 routers. Ipv4-compatible addresses
technology that uses 53-byte cells (packets) have their 96 high-order bits set to zero and
to simultaneously transmit different types of 32 low-order bits set to an IPv4 address.
data, including video and voice. Using this technique, dual-stacked nodes
can use the same address for IPv4 and IPv6
C packets.
Community String A plain text password IPv6 Global-Scoped Addresses These

used to authenticate SNMP queries to addresses, normally referred to as
SNMP agents. aggregatable global unicast addresses, refer
to IPv6 addresses that begin with 001. At
D some future time, IPv6 global-scoped
addresses may include other currently
Dual Stack A router or host that is unassigned unicast IPv6 prefixes.
configured for both IPv4 and IPv6.
IPv6 Link-Local Scoped Addresses
Dynamic Views Describes the family of These addresses are only used to connect
browser-based views whose content is neighboring nodes. Link-local addresses
created as a result of choices you make when always have the prefix 1111 1110 10 in the
you launch the view, and which continue to first ten bits. Almost all IPv6 addresses will
provide the most current status information have a link-local address.
available.
IPv6 Prefix Group A prefix group is
H similar to a subnet in IPv4. A prefix group
has a specific scope: site-local scoped
Home Base The main launching point for addresses or global-scoped addresses. There
Dynamic Views. are no prefix groups for link-local scoped
addresses.
Glossary 323
Glossary
IPv6 Site-Local Scoped Addresses
IPv6 Site-Local Scoped Addresses These S
addresses can only be used within an
isolated internet. Site-local scoped addresses SNMP Simple Network Management
always have the prefix 1111 1110 11 in the Protocol. A standard protocol used to
first ten bits. manage TCP/IP networks.
M T
MIB Management Information Base. In the Threshold A preset, calculated, or MIB
context of managed devices, a collection of instance value used in NNM data collection.
objects that can be accessed via a network NNM can generate an alarm when a
management protocol. threshold violation occurs.
N Tunneling Enabling network

communication between two IPv6 networks
Neighbors Two devices that have directly by forwarding IPv6 packets across an IPv4
connected interfaces. network.
O V
OAD Overlapping Address Domains. The VCI Virtual Channel Identifier. The address
OAD denotes a set of unique, private IP or label of an ATM Virtual Circuit.
addresses. The OAD view is useful when
monitoring several OADs that contain VLAN Virtual LAN. The creation of multiple
overlapping private IP addresses. logical networks within a single physical
network or switching device. Each VLAN
OSI Model Open Systems Interconnect creates a new broadcast domain.
Model. A network design framework
established by the ISO (International VPI Virtual Path Identifier. The address of
Standards Organization) to provide an ATM virtual path.
equipment from different vendors to be able
to communicate.
OSPF Open Shortest Path First protocol. A

protocol that routers use to communicate
between themselves. OSPF has the ability to
configure topologies and adapt to changes in
the Internet.
Port Aggregation A method of connecting

two Ethernet switches with two or more
cables.
324 Glossary
Index
A APA Node Down, 198, 199, 204, 209
Active Problem Analyzer APA Node Intermittent, 198, 204
see APA, 86 APA Node Renumbering, 226
Advanced Routing SPI, 86, 238 APA Node Up, 204, 226
discovering OV_HSRP, 225
HSRP information, 238 OV_HSRP State Change, 202
IPv6 information, 239 OV_Link_Down, 209
OSPF information, 238 OV_Link_Intermittent, 198, 203
discovery APA, 86, 127
IPv6, 240 adjusting polling engine threads, 117
IPv6 configuration files, 240 adjusting polling parameters, 112
HSRP paConfig.xml file, 112
discovery, 257 adjusting status analyzer threads, 116
IPv6 advantages, 89, 90
configuration files, 240 alarm reduction, 102
discovery, 240 alarms
IPv6 Global Network view, 244 Address Down, 199, 206
Prefix Groups, 245 Address Intermittent, 199, 206
references, 264 Address Up, 206
Site-Local Network view, 248 Aggregated Port, 202, 227
troubleshooting discovery, 242 Board Down, 200, 216
IPv6 Global Network view, 244 Connection Down, 199, 207, 210, 224
OSPF Connection Intermittent, 199, 207
discovery procedure, 252 Connection Unreachable, 199, 210, 224
references, 264 Connection Up, 201, 207, 224
troubleshooting discovery, 253 defined, 102
OSPF view Demand Analysis, 201, 220
troubleshooting with, 254 HSRP, 202
advantages of using APA, 89, 90 Interface Down, 199, 201, 205, 224
Agent MSI, 164, 168 Interface Intermittent, 199, 205
aggregated port Interface Unreachable, 224
about term, 198 Interface Up, 224
correlating events, 227 Node Down, 198, 199, 204, 209
alarms Node Intermittent, 198, 204
APA Address Down, 199, 206 Node Renumbering, 226
APA Address Intermittent, 199, 206 Node Up, 204, 226
APA Address Up, 206 changing default polling interval, 113
APA Aggregated Port, 202, 227 changing device class polling interval, 114
APA Board Down, 200, 216 compared to netmon, 91
APA Connection Down, 199, 207, 210, 224 configuring, 110
APA Connection Intermittent, 199, 207 Connector Down correlation, 105
APA Connection Unreachable, 199, 210, 224 cooperation with netmon, 89, 93
APA Connection UP, 201, 224 default polling configuration, 87
APA Connection Up, 207 described, 86
APA Demand Analysis, 201, 220 disable
APA Interface Down, 199, 201, 205, 224 using ovet_apaConfig.ovpl script, 109
APA Interface Intermittent, 199, 205 disable from polling specific nodes, 138
APA Interface Unreachable, 224 disable HSRP group polling, 127
APA Interface Up, 224 disable ICMP polling
325
Index
for various ifTypes, 135 Status Analyzer, 112, 127
of specific addresses, 142 Status Bridge, 113, 127
disabling correlators, 232 suppress or allow APA status polling, 125
do not enable on management stations, 89 Talker, 112
Dynamic Views status, 100 trigger poll correlators, 219
ECS correlations, 105 unconnected switch ports
emitting alarms for important nodes, 118 disable SNMP polling, 133
enable, 109 enable SNMP polling, 133
paConfig.xml file, 109 using topology filters, 120
using ovet_apaConfig.ovpl script, 109 APA Address Down alarm
enable HSRP group polling, 127 correlating, 199
enable on collection stations, 89 generating flapping event, 206
event reduction, 102 APA Address Intermittent alarm, 199, 206
existing filters, 121 APA Address Up alarm
failure analysis, 94 generating flapping event, 206
FAQ, 146 APA Aggregated Port alarm
forwarding status information, 93 correlating with LinkDown, 202, 227
general IPv4 interfaces, 89, 109 correlating with syslog, 202
HSRP group polling generating, 229
disabling, 128 nesting secondary events, 229
enabling, 128 APA Board Down alarm, 200, 216
APA Connection Down alarm
HSRP monitoring, 86 correlating with LinkDown, 199, 210
HSRP status, 100 correlating with OSPF, 224
ICMP polling generating flapping event, 199, 207
disabling, 131 APA Connection Intermittent alarm, 199, 207
enabling, 131 APA Connection Unreachable alarm
important nodes, 118 correlating with LinkDown, 199, 210
netmon device discovery, 89 correlating with OSPF, 224
no IPX support, 101 APA Connection Up alarm
node status, 101 correlating with OSPF, 201, 224
OAD (Overlapping Address Domain), 86 generating flapping event, 207
OAD monitoring, 86 APA correlators. See correlators
OV_PollerIntermittent correlators, 104 APA Demand Analysis alarm
ovet_poll process, 92, 102, 127 about, 201
starting and stopping, 114, 115, 117, 118, generating, 220
124, 128, 129, 131 APA HSRP alarm, 225
Pair Wise correlation, 105 APA Interface Down alarm, 199
Polling Engine, 112, 127 correlating with OSPF, 201, 224
polling statistics, 110 generating flapping event, 205
Active Analyzer Tasks, 110 APA Interface Intermittent alarm
Addresses Polled, 111 generating flapping event, 199, 205
Boards Polled, 111 APA Interface Unreachable alarm
HSRP Groups Polled, 111 correlating with OSPF, 224
Interfaces Polled, 111 APA Interface Up alarm
correlating with OSPF, 224
Waiting Analyzer Tasks, 111
APA Node Down alarm, 209
Waiting Poller Tasks, 110 correlating LinkDown, 199
SNMP polling generating flapping event, 198, 199, 204
disabling, 130 APA Node Intermittent alarm
enabling, 130
326
Index
generating flapping event, 198, 204 editing namespace file, 233
APA Node Renumbering alarm, 226 factstore files, 233
APA Node Up alarm, 226 related documentation, 235
generating flapping event, 204 removing namespaces, 233
APA poll saving definitions, 231
configuration request, 219 troubleshooting, 235
force request, 219 viewing namespaces, 230
issuing request, 220 Composer correlators. See correlators
status request, 219 Composer parameters
Up/Down request, 219 Count, 203, 204, 205, 206, 208
Application setting, 230
OVO template condition field, 187 Window Period, 203, 204, 205, 207, 208, 210,
Automatic Zone Discovery, 23 211
Composer window, 230, 232
B Correlator Store pane, 230
board NameSpace table, 230
about term, 198 Condition Text field, 181
Board Down configuration options
correlating with APA Board Down, 216 Syslog Integration, 150
correlating with syslog Board Down, 214 configuration poll, 219
syslog messages, 216 configuring
Board Down event, 200, 212, 216 Ospf.cfg file, 252
bridge.noDiscover file, 32 ovweb.conf file, 15
brownout events, 58, 69 recurring discovery, 36
brownout parameters connection editor, 302
BROWNOUT_BAD_SAMPLES, 70 how to use, 304
BROWNOUT_INTERVAL, 69 when to use, 299, 302
BROWNOUT_NUM_ DEVIATIONS, 70 correlating with Board Down, 214
BROWNOUT_NUM_SAMPLES, 70 Correlation Composer. See Composer
BUCKET_SIZE, 70 correlators
BROWNOUT_BAD_SAMPLES, 70 about aggregated port events, 202
BROWNOUT_INTERVAL, 69 about APA, 198
BROWNOUT_NUM_ DEVIATIONS, 70 about APA Board Down events, 200
BROWNOUT_NUM_SAMPLES, 70 about APA poll trigger events, 201
browser about Board Down events, 200
configuring path in ovweb.conf file, 15 about flapping events and APA, 198, 203
BUCKET_SIZE, 70 about LinkDown and APA alarms, 199
about NNM, 196
C about Syslog Integration and APA, 196
card. See board deploying, 233
Cold Start event, 202, 225 deploying in Composer, 231, 233
Cold Start events description, 196
listening for, 226 detecting address flapping, 206
command detecting connection flapping, 207
ovstart, 36 detecting interface flapping, 205
ovstatus -v ovet_disco, 277 detecting multiple LinkDown events, 203
xnmevents, 272 detecting node flapping, 204
Composer disabling, 232
deploying correlators, 231, 233 disabling group, 233
disabling correlators, 232 LinkDown with APA Aggregated Port, 227
327
Index
LinkDown with APA Connection Down, 210 supported by Extended Topology, 276
LinkDown with APA Node Down, 209 disable correlators
namespaces, 198 using Composer, 232
nesting aggregated port events, 227 using namespace file, 233
nesting Board Down under APA Board disabling Syslog Integration, 191
Down, 216 discovery
nesting LinkDown under Board Down, 212 editing with connection editor, 302
nesting LinkDown under syslog Board HSRP, 257
Down, 213 in Extended Topology, 16, 20
nesting poll trigger events, 201, 224 troubleshooting, 277
OV_Addr_IntermittentStatus, 206 limiting, 32
OV_APA_AggregatedPort, 227, 228 nodes, boards, interfaces, and addresses, 91
OV_APA_BoardDown, 217 OSPF, 16, 252
OV_Board_Down, 212 single zone, 38
OV_Board_Trap_SyslogCorr, 200, 215 unresponsive devices, 34
OV_Connection_IntermittentStatus, 207 zones, 20, 23
OV_HSRP_APA, 225 Dynamic Views
OV_HSRP_StateChange, 225 accessing from NNM Alarm Browser, 17
OV_Interface_IntermittentStatus, 205 accessing online help, 17
OV_Link_Down, 209, 210, 212, 213, 227 APA status, 100
OV_Link_Down2, 212, 213 ATM information, 14
OV_Link_Intermittent, 203 described, 14
OV_LinkDown_NodeDown, 209 Extended Topology information
OV_Node_IntermittentStatus, 204 use object’s primary collection station, 22
OV_Node_Restart_Trap, 226 modifying menu items, 18
OV_NodeRestart_APA, 226 Neighbor view, 14
OV_NodeRestart_Syslog, 226 Node view, 14
OV_OSPF_AdjacencyChange, 224 Path view, 14
OV_OSPF_APA, 224 security, 32
OV_Port_Aggregation, 228 showing status information, 93
OV_Syslog_BoardDown, 217 VLAN view, 14
OV_Syslog_LinkDown, 212, 213, 227 dynamicViewsUsers.xml file, 32
syslog aggregated port with APA, 228
syslog Down with APA Aggregated Port, E
227 ECS
triggering APA poll, 219 layer 2 and 3 network paths, 274
troubleshooting, 235 PairWise correlation, 203, 204, 205, 206, 207
Count parameter, 203, 204, 205, 206, 208 ECS Configuration window, 230, 232
custom message attributes (CMAs), 188, 189 etrestart.ovpl
-force option, 24
D manpage, 31, 36
script, 24, 28, 29, 31, 37, 38, 278
DCE requirements, 160 Event Configuration window, 230, 232
DCE RPC, 160 events
DCE-KT-Tools, 160 Board Down, 200, 212, 216
deploy correlators, 233
in Composer, 231, 233 Cold Start, 202, 225
deployment options correlating flapping with APA, 203
Syslog Integration, 150 HSRP State Change, 202, 225
devices LinkDown, 198, 199, 200, 202, 212, 213
328
Index
OSPF Adjacency Change, 201, 224 extended topology
PAGP_JoinedBridgePort, 229 differs from Extended Topology, 88
PAGP_LeftBridgePort, 229 Extended Topology Discovery, 23
syslog aggregated port, 228
Warm Start, 202, 225 F
Extended Topology factstore files
accessing NNM Release Notes, 18 location, 233
accessing online help, 18 FAQ, 146
accessing this manual, 18 file
backing up configuration files, 276 bridge.noDiscover, 32
checking for latest patches, 276 dynamicViewsUsers.xml, 32
configuring recurring discovery, 36 IPv6.conf, 240
connection editor, 302 IPv6Polling.conf, 240
deployment tips, 294 IPv6Prefix.conf, 240
differs from extended topology, 88 IPv6Scope.conf, 240, 241
discovery, 16, 20 IPv6Seed.conf, 240
basics, 20 Ospf.cfg, 252
configuring, 36 ovweb.conf, 16
limiting, 32 xnmeventsExt.conf, 272
nodes, boards, interfaces, and addresses, flapping events
91 correlating address up/down, 206
recurring, 36 correlating connection up/down, 207
status of, 33 correlating interface up/down, 205
troubleshooting, 277 correlating node up/down, 204
unresponsive devices, 34 correlators, 203
zones, 20, 23 force poll, 219
Discovery Exclusion List, 32 triggering request, 219
discovery tips, 296
editing connections, 302 G
information discovered by, 21 general IPv4 interfaces, 89
board and port information, 21 polling, 90
layer 2 information, 21
port aggregation, 21 H
VLAN information, 21 Home Base, 16
introducing, 14 accessing, 16
NNM and Extended Topology, 14 checking discovery status, 33
post discovery tips, 298 definition, 16
prediscovery tips, 294 described, 16
recurring discovery URL, 16
configuring, 34 hosts.nnm file, 89, 101, 109
supported HSRP
devices, 276 correct handling of virtual IP addresses,
JPI versions, 15 257
web browser, 15 discovery, 257
troubleshooting validating results, 259
discovery, 277 group status information, 260
views, 280 HSRP group polling
use object’s primary collection station, 22 disabling, 127
using SNMP community strings, 30, 31 enabling, 127
329
Index
HSRP polling message source templates
disabling, 128 overview, 173
enabling, 128 Message Source Templates interface, 155,
HSRP State Change event, 202, 225 164, 168, 174
HSRP State Change events assigning templates, 165, 169
listening for, 225 installing templates, 165, 169
viewing suppressed, 225 Message Source Templates window
starting, 176
I message stream interface
troubleshooting, 192
ICMP polling message stream interface (MSI), 164, 168
disabling, 131 Message Text
enabling, 131 OVO template condition field, 186, 188
important nodes, 118 Message Type
IPv6 OVO template condition field, 188
events, 250 message type
understanding status information, 248 NNMsyslog_, 151, 188
module. See board
J ModuleDown event. See Board Down event
JPI versions MSI
supported, 15 enabling OVO agent, 164, 169
enabling template, 164, 168
L
N
LinkDown event, 198, 199, 200, 202, 212, 213
LinkDown events namespace file
correlating repeated, 203 location, 233
correlating with APA Aggregated Port, 227 NameSpace.conf file, 233
correlating with APA Connection Down, 210 namespaces
viewing suppressed, 228 OV_CiscoBoard, 200, 212
viewing suppressed in browser, 214 OV_PollerBoardDown, 200, 216
log files OV_PollerIntermittent, 198, 203
controlling, 317 OV_PollerLinkDown, 199, 209
switching on and off, 321 OV_PollerPortAgg, 202, 227
logfile OV_PollerTrigger, 201, 219
syslog.log, 192 OV_PollerTriggerCorr, 201, 224
logger, 162, 166, 170 removing from Composer, 233
Neighbor view
M accessing, 16
and board/port information, 268
manpage
bridge.noDiscover, 32 and port aggregation, 267
etrestart.ovpl, 31, 36 troubleshooting with, 266, 269, 270
ovsnmp.conf_db, 30 netmon
device discovery for APA, 89
ovstart, 36
netpath_http
ovweb.conf, 15 /etc/services entry, 71
setupExtTopo.ovpl, 30, 36 NIS
xnmsnmpconf, 31 syslog requirement, 161
Message Group NNM
OVO template condition field, 187 environment variables, 15
Message on Matched Condition Extended Topology and NNM, 14
OVO template condition field, 187
330
Index
Release Notes, 18 OV_Addr_IntermittentStatus correlator
starting, 183 behavior, 206
universal path names, 15 setting parameters, 206
NNM Advanced Edition, 14 OV_APA_ADDR_DOWN. See APA Address
NNM standalone configuration Down alarm
configuring syslog monitoring, 155 OV_APA_ADDR_Intermittent. See APA
deploying, 156 Address Intermittent alarm
deploying templates, 190 OV_APA_ADDR_UP. See APA Address Up
describing Syslog Integration, 151 alarm
disabling, 171 OV_APA_AggregatedPort correlator
behavior, 227, 228
setting up, 155, 162 OV_APA_BoardDown correlator
testing, 162 behavior, 217
NNM Syslog Trap Mapping Configuration OV_APA_CONN_Intermittent. See APA
Interface Conenction Intermittent alarm
about, 153 OV_APA_CONNECTION_DOWN. See APA
NNMsyslog_ message type, 151, 188 Connection Down alarm
NNMsyslogTraps, 164, 167 OV_APA_CONNECTION_UNREACHABLE
Node . See APA Connection Unreachable alarm
OVO template condition field, 185, 187 OV_APA_CONNECTION_UP. See APA
Node view Connection Up alarm
accessing, 16 OV_APA_IF_DOWN. See APA Interface
npprobe.conf file, 67, 71 Down alarm
OV_APA_IF_Intermittent. See APA Interface
O Intermittent alarm
OAD, 86 OV_APA_IF_UNREACHABLE. See APA
see Overlapping Address Domain, 42 Interface Unreachable alarm
OV_APA_IF_UP. See APA Interface Up
Object alarm
OVO template condition field, 187 OV_APA_NODE_DOWN. See APA Node
online help Down alarm
accessing from Dynamic Views, 17 OV_APA_NODE_Intermittent. See APA
opc Node Intermittent alarm
starting OVO, 155 OV_APA_NODE_UP. See APA Node Up
opc command alarm
starting OVO, 176 OV_Board_Down correlator
opc_op behavior, 212
add OVO user locally, 161 OV_Board_Trap_SyslogCorr correlator
opccfgupld, 164, 168 about, 200
opcpat, 190 behavior, 215
opctemplate, 193 OV_CiscoBoard namespace
OSPF about, 200, 212
configuring Ospf.cfg file, 252 OV_Connection_IntermittentStatus
correlating Adjacency events, 224 correlator, 207
discovery, 16 setting parameters, 208
ospfdis.err file, 252 OV_HSRP
ospfdis.ovpl script, 252 generating alarm, 225
suggested reference material, 253 State Change alarms, 225
supported MIBs, 252 OV_HSRP state change alarm, 202
OSPF Adjacency Change event, 201, 224 OV_HSRP_APA correlator
OSPF Adjacency events behavior, 225
viewing suppressed, 225 OV_HSRP_StateChange correlator
331
Index
behavior, 225 OV_Syslog_LineProtoDown, 157
OV_Interface_IntermittentStatus correlator OV_Syslog_LineProtoUp, 157
behavior, 205 OV_Syslog_LinkDown, 157
setting parameters, 205 OV_Syslog_LinkDown correlator
OV_Link_Down alarm, 209 behavior, 212, 213, 227
OV_Link_Down correlator, 210 OV_Syslog_LinkUp, 157
behavior, 209, 212, 213, 227 OV_Syslog_OSPF_Neighbor_Down, 157
setting parameters, 210 OV_Syslog_OSPF_Neighbor_Up, 157
OV_Link_Down2 correlator Overlapping Address Domain, 22
behavior, 212, 213 and undiscovered NAT devices, 48
OV_Link_Intermittent alarm, 198, 203 configuring discovery, 43
OV_Link_Intermittent correlator configuring SNMP data collection, 53
behavior, 203 defined, 42
OV_LinkDown_ConnDown correlator deleting a single zone, 46
behavior, 210 discovery, 46
setting parameters, 211 see OAD, 86
OV_LinkDown_NodeDown correlator understanding status, 53
behavior, 209 undiscovered NAT devices
setting parameters, 210 remedy with NextHop keyword, 50
OV_Node_IntermittentStatus correlator ovet_apaConfig.ovpl script, 109
behavior, 204 ovet_poll process, 92, 102, 127
setting parameters, 204 starting and stopping, 114, 115, 117, 118,
OV_Node_Restart_Trap correlator 124, 128, 129, 131
behavior, 226 ovet_topodump.ovpl script, 120, 121
OV_NodeRestart_APA correlator ovet_toposet command, 125
behavior, 226 OVO agent
OV_NodeRestart_Syslog correlator in NNM standalone configuration, 155, 173
Behavior, 226 in Syslog Integration
OV_OSPF_AdjacencyChange correlator NNM Standalone configuration, 151
behavior, 224 OVO with NNM configuration, 153
OV_OSPF_APA correlator OVO server
behavior, 224 in OVO with NNM configuration, 153
OV_PollerBoardDown namespace OVO template condition field
about, 200, 216 Message Group, 187
OV_PollerIntermittent correlators, 104 Message Text, 188
OV_PollerIntermittent namespace Message Type, 188
about, 198, 203 Node, 187
OV_PollerLinkDown namespace Service Name, 188
about, 199, 209 OVO templates
OV_PollerPortAgg namespace troubleshooting, 193
about, 202, 227 OVO with NNM configuration
OV_PollerTrigger namespace described, 153
about, 201, 219 disabling, 171
OV_PollerTriggerCorr namespace setting up, 156, 163, 167
about, 201, 224 testing, 166, 170
OV_Port_Aggregation correlators ovsnmp.conf_db
behavior, 228 manpage, 30
OV_Syslog_BoardDown correlator ovstart
behavior, 217 command, 36
OV_Syslog_FrameDLCI_Active, 157 manpage, 36
OV_Syslog_FrameDLCI_Inactive, 157
332
Index
ovstart command, 73 running standalone, 77
ovstatus -v ovet_disco command, 277 starting, 73
ovstop command, 73 stopping, 74
ovsyslogcfg, 155, 162, 174 Problem Diagnosis, 56
ovtrap2opc, 166, 170 changing ports, 70
in OVO with NNM configuration, 154 configuring brownouts, 69
ovweb.conf configuring probe targets, 72
file, 16 configuring probes, 72
manpage, 15
configuring server port, 71
ovweb.conf file database, 82
changing browser location path, 15
probes, 57, 60
server, 56
P starting probe, 73
paConfig.xml file, 109, 112, 120 starting server, 73
PAGP_JoinedBridgePort event, 229 stopping server, 73
PAGP_LeftBridgePort event, 229 view, 56, 59, 72
parameters Problem Diagnosis database
Count, 203, 204, 205, 206, 208 fixing a corrupt, 82
setting, 230 Problem Diagnosis probes
Window Period, 203, 204, 205, 207, 208, 210, about, 57
211 changing port, 71
Path view checking status, 83
accessing, 16 configuring, 67
pdcentral.sh command, 74, 83 standalone mode, 77
pdconfig.xml, 69, 71
pdconfig.xml file, 64, 65, 69, 71 starting, 73, 74
pdpinstall.sh command, 61 stopping, 74
pdpinstall.vbs command, 63 Problem Diagnosis server
pmd about, 56
in OVO with NNM configuration, 154 changing port, 71
pmd process checking status, 83
describing role configuring, 64
Syslog Integration, 152 configuring probes, 65
poll starting, 73
issuing request, 220 stopping, 73
trigger configuration request, 219 publications
poll triggering events Correlation Composer’s Guide, 196, 235
correlating, 224 Managing Your Network, 196
Polling Engine, 127
Probes R
configuring targets, 72
probes RAMS (Route Analytics Management
about, 57 System), 238
recurring discovery
changing port, 71 configuring in Extended Topology, 34
checking status, 83 Release Notes
installing on HP-UX, 61 accessing, 18
installing on Solaris, 62 RELOAD
installing on Windows, 63 syslog message, 226
installing remote, 60 RESTART
linking server to, 67 syslog messages, 226
linking to server, 65
333
Index
S describing, 150
script disabling, 190
etrestart.ovpl, 24, 28, 29, 31, 37, 38, 278 in NNM Standalone configuration, 190
ospfdis.ovpl, 252 in OVO with NNM configuration, 191
setupExtTopo.ovpl, 36 logfile
Service Name syslog.log, 192
OVO template condition field, 188 OVO agent
setupExtTopo.ovpl in NNM standalone configuration, 151
manpage, 30, 36 in OVO with NNM configuration, 153
script, 30, 36 OVO with NNM configuration
setupSyslog.ovpl, 155 describing, 153
-deploy option, 156, 190 pmd process, 152
-disable option, 171, 190 removing, 171
-help option, 155 starting syslog process, 191
-server option, 156, 163, 167 stoppping syslog process, 191
-standalone option, 155, 162 system logfile, 192
setupSyslog.ovpl command template
-disable option, 191 Syslog to NNM, 177
Site-Local Network view, 248 troubleshooting
SNMP community strings duplicate messages in browser, 192
used by Extended Topology, 30, 31 not seeing messages in browser, 193
SNMP polling Syslog LINEPROTO down, 179
disabling, 130 Syslog LINEPROTO up, 179
enabling, 130 Syslog LINKDOWN, 179
SNMP Traps template, 166, 170 Syslog LINKUP, 179
Status Analyzer, 127 syslog logfile
Status Bridge, 127 location, 192
status poll, 219 syslog message
supported devices Link Down
obtaining information about, 276 viewing suppressed in browser, 214
Suppress Matched Condition syslog messages
OVO template condition field, 186 aggregated port
Suppress Unmatched Condition correlating with APA alarm, 202, 228
OVO template condition field, 186 Board Down, 214
syslog correlating beneath, 200, 212
correlating Down events with APA
correlating with APA Board Down, 216
Aggregated Port, 227
correlating with syslog Board Down, 213
syslog aggregated port event, 228
syslog Board Down events generating OV_Syslog_ alarms, 151
correlating with Board Down, 214 Line Protocol Down
correlating with syslog Down events, 213 correlating with APA Aggregated Port,
Syslog FRAME DLCI Active, 179 227
Syslog FRAME DLCI Inactive, 179 correlating with Board Down, 212
Syslog FRAME DLCI Invalid, 179 correlating with syslog Board Down, 200,
Syslog Integration 213
and APA correlators, 196 viewing suppresed in browser, 214
configuring, 162, 163, 167 Link Down
deployment options correlating with APA Aggregated Port,
describing, 150 227
NNM standalone, 151 correlating with Board Down, 212
334
Index
correlating with syslog Board Down, 200, trunk. See aggregated port
213
RELOAD, 202, 225 U
RESTART, 202, 225, 226 unconnected switch ports
seeing duplicate in browser, 192 disable SNMP polling, 133
viewing suppressed, 228 enable SNMP polling, 133
viewing suppressed aggregated port, 229
Syslog OSPF Adjacency down, 179 V
Syslog OSPF Adjacency up, 179
Syslog to NNM template, 153, 154, 155, 173 view
assigning to agent, 165, 169 Problem Diagnosis, 56, 59, 72
Condition Text field, 181 views
deploying, 190 see Dynamic Views, 14
describing, 177 VLAN view
in NNM standalone configuration, 181 accessing, 16
troubleshooting with, 268, 270
in OVO with NNM configuration, 184
syslog trap mappings, 156
uploading in OVO with NNM configuration, W
164, 168 Warm Start event, 202, 225
Syslog Trap Mapping Configuration Warm Start events
interface, 174 listening for, 226
starting, 155 web browsers
syslog.log file, 192 supported, 15
syslogTrap window
in NNM standalone configuration, 155 Composer, 230, 232
in OVO with NNM configuration, 154 ECS Configuration, 230, 232
starting in OVO with NNM configuration, Event Configuration, 230, 232
166, 170 Message Source Templates, 176
syslogTrap process NNM Syslog Mapping Configuration, 153
in NNM standalone configuration, 151 Problem Diagnosis Configuration, 72
starting in OVO with NNM configuration, Status Alarms Browser, 225, 226, 228
191 Window Period parameter, 203, 204, 205, 207,
stopping in NNM standalone configuration, 208, 210, 211
190
stopping in OVO with NNM configuration, X
191 xnmevents
command, 272
T xnmeventsExt.conf file
Talker, 127 launching view and URLs, 272
template condition modifying, 272
testing syntax, 190 xnmsnmpconf
templates manpage, 31
deploying in NNM standalone, 190
verifying installed, 193 Z
testing configuration, 162 Zone-based Configuration
trap OID, 182 automatic, 24
trapd.conf, 153 manual, 26
troubleshooting Zone-based Discovery, 23
Composer, 235 automatic zone discovery, 23
syslog messages, 192, 193
335

Using Extended Topology

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Using Extended Topology

Caricato da

Copyright:

Formati disponibili

HP OpenView Network Node Manager

Using Extended Topology

Windows, HP-UX, and Solaris operating systems

Manufacturing Part Number : T2490-90030

© Copyright 2002-2004 Hewlett-Packard Development Company, L.P.

2. Extended Topology Discovery

3. Configuring Overlapping Address Domain Discovery

5. Using the Active Problem Analyzer

7. APA and Event Reduction

8. The Advanced Routing Smart Plug-in

9. Diagnosing Network Problems with Extended Topology

10. Maintaining Extended Topology

A. Common Zone Configuration Examples

B. Successfully Deploying Extended Topology: Practical Deployment Tips

C. Modifying Connections with the Connection Editor

D. Controlling Log Files

Introducing the Extended Topology

Extended Topology discovers and displays additional device connectivity

NOTE Extended Topology collects information from devices discovered by NNM.

Dynamic Views describes the family of browser-based views whose

Extended Topology and the NNM Environment

• UNIX: $OV_LOG rather than /var/opt/OV/share/log

• UNIX: $OV_BIN rather than /opt/OV/bin

Extended Topology and the Web Browser

If the Extended Topology installation program can’t find a web browser

Accessing Dynamic Views

• From the NNM menu, Tools:Views.

Figure 1-1 NNM’s Home Base

1. Select an alarm from the Alarm Browser.

Modifying Dynamic View Menus

Obtaining More Information about Extended

Figure 1-2 Selecting the HP OpenView Web Online Help

• View the NNM Release Notes from NNM: Help->NNM->Release

The Basics of Extended Topology Discovery

NOTE Extended Topology collects detailed information from devices whose

What Extended Topology Discovers

Discovering Layer 2 Information

Discovering VLAN Information

Discovering Board and Port Information on Cisco Devices

Discovering Multiple Links Between Two Devices

Discovering ATM information

Discovering Overlapping Address Domain Information

Discovering and Distributing Extended Topology Information

Running Extended Topology Discovery

• It determines the protocols your environment supports and decides

Automatic Zone Configuration

1. Open the Configure Extended Topology GUI using the NNM

NOTE The etrestart.ovpl script will not interrupt a discovery in progress

If you request that Extended Topology configure zones automatically at a

1. From Home Base, select the Discovery Status tab.

Verifying and Modifying Your Zone Configuration

• NNM discovers new nodes.

1. Open the Configure Extended Topology GUI using the NNM

Manually Configuring Zones

To manually organize your devices into zones, use the following

1. Open the Configure Extended Topology GUI using the NNM

NOTE When the Extended Topology discovery process begins, NNM

5. In the Zone:Administration text box you can specify any hostname

• Asterisk: Use an asterisk to represent any number of characters

*.* matches corp.com or pc.com, but not pc.corp.com.

Transferring Information from NNM to Extended

• NNM IP address and hostname information.

NOTE Extended Topology uses the information it receives from NNM to

Use the Options:Configuration-->SNMP Configuration menu to

. matches corp.com or pc.com, but not pc.corp.com.