Robust Topology Optimization of Structures using Kriging ...
Using Extended Topology
Transcript of 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 NoticesWarranty.
Hewlett-Packard makes no warranty of any kind with regard to thismanual, including, but not limited to, the implied warranties ofmerchantability and fitness for a particular purpose. Hewlett-Packardshall not be held liable for errors contained herein or direct, indirect,special, incidental or consequential damages in connection with thefurnishing, performance, or use of this material.
A copy of the specific warranty terms applicable to your Hewlett-Packardproduct can be obtained from your local Sales and Service Office.
Restricted Rights Legend.
Use, duplication or disclosure by the U.S. Government is subject torestrictions as set forth in subparagraph (c)(1)(ii) of the Rights inTechnical Data and Computer Software clause in DFARS 252.227-7013.
Hewlett-Packard CompanyUnited States of America
Rights for non-DOD U.S. Government Departments and Agencies are asset 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 toanother language without the prior written consent of Hewlett-PackardCompany. The information contained in this material is subject tochange 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 aregistered trademark of Riversoft Technologies Limited. NMOS™ is atrademark of Riversoft Technologies Limited. All rights reserved.
2
Netscape™ and Netscape Navigator™ are U.S. trademarks of NetscapeCommunications Corporation.
Oracle® is a registered U.S. trademark of Oracle Corporation, RedwoodCity, California.
Oracle7™ is a trademark of Oracle Corporation, Redwood City,California.
OSF/Motif® and Open Software Foundation® are trademarks of OpenSoftware 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 trademarkor service mark holders and are hereby acknowledged.
3
4
Contents
1. Introduction to Extended Topology FunctionalityIntroducing the Extended Topology Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Extended Topology and the NNM Environment Variables . . . . . . . . . . . . . . . . . . . . 15Extended Topology and the Web Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Modifying Dynamic View Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Obtaining More Information about Extended Topology . . . . . . . . . . . . . . . . . . . . . . 18
2. Extended Topology DiscoveryThe Basics of Extended Topology Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
What Extended Topology Discovers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Running Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Automatic Zone Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Manually Configuring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Transferring Information from NNM to Extended Topology . . . . . . . . . . . . . . . . . . . 29Limiting Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Setting up Dynamic View Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Viewing Discovery Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Understanding Recurring Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Configuring Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Discovering Devices in a Single Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3. Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains . . . . . . . 42
Configuring Extended Topology to Discover and Monitor Overlapping Private InternetAddresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Understanding OAD View Status Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Data Collections & Thresholds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4. Problem DiagnosisIntroducing Problem Diagnosis Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Major Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56About Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Starting a Problem Diagnosis View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Installing Remote Probes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Configuring Problem Diagnosis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Linking Servers and Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Configuring Brownouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Configuring Server and Probe Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5
Contents
Configuring Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Other Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Starting and Stopping the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Starting and Stopping a Probe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Limitations and Oddities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Java Oddities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Troubleshooting Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Cleaning Up a Corrupt Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Checking Status of Problem Diagnosis Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Checking Status of Remote Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5. Using the Active Problem AnalyzerUnderstanding the Basics of the Active Problem Analyzer. . . . . . . . . . . . . . . . . . . . . . 86Understanding How APA and the netmon Process Cooperate . . . . . . . . . . . . . . . . . . . 89
How APA and the netmon Process Share Information. . . . . . . . . . . . . . . . . . . . . . . . 93How APA Looks at Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Understanding APA and View Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Understanding APA and HSRP Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Understanding APA, Layer 3 Polling, and Node Status . . . . . . . . . . . . . . . . . . . . . 101
Understanding APA and Event Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Configuration Polling and Interface Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 105
Enabling and Disabling APA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Configuring APA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Understanding APA Polling Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Adjusting APA Polling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Using Topology Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Suppress or Allow APA Status Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Controlling Other APA Polling Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Enable or Disable Global HSRP Group Polling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Enable or Disable HSRP Polling for Devices not Belonging to a Device Class . . . . 128Enable or Disable SNMP Polling of Devices not Belonging to a Device Class . . . . 130Enable or Disable ICMP Polling of Devices not Belonging to a Device Class . . . . . 131Enable or Disable SNMP Polling for Unconnected Switch Ports . . . . . . . . . . . . . . . 133Disable ICMP Polling for ISDN, SLIP, and Other ifTypes . . . . . . . . . . . . . . . . . . . . 135Disable APA from Polling Specific Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6
Contents
Disable APA from Using ICMP to Poll Specific Addresses. . . . . . . . . . . . . . . . . . . . 142Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6. Syslog IntegrationIntroducing the Syslog Integration Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Syslog Integration Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Configuration Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Default Syslog Trap Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring Syslog Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Prerequisites for Configuring Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Configuring Syslog Integration for NNM Standalone . . . . . . . . . . . . . . . . . . . . . . . 161Configuring Syslog Integration for OVO with NNM on the Same System . . . . . . . 163Configuring Syslog Integration for OVO with NNM on Separate Systems. . . . . . . 167Removing Syslog Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Customizing Message Source Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Overview of Message Source Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Understanding the Template Configuration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 174Understanding the Syslog to NNM Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177How Syslog to NNM Conditions Function in the NNM Standalone Configuration 181How Syslog to NNM Templates Function in the OVO with NNM Configuration. . 184
Maintaining Syslog Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Administrative Tasks for NNM Standalone Configurations . . . . . . . . . . . . . . . . . . 190Administrative Tasks for OVO with NNM Configurations . . . . . . . . . . . . . . . . . . . 191
Troubleshooting Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192System Logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
7. APA and Event ReductionNNM’s Event Reduction Capabilities When APA Is Enabled . . . . . . . . . . . . . . . . . . . 196
Correlation Composer and APA Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Syslog Integration and APA Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Overview of APA Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198OV_PollerIntermittent Namespace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Multiple LinkDown Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Node Intermittent Status Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Interface Intermittent Status Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Address Intermittent Status Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7
Contents
Connection Intermittent Status Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207OV_PollerLinkDown Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
LinkDown Events and APA Node Status Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . 209LinkDown Events and APA Connection Status Alarms. . . . . . . . . . . . . . . . . . . . . . 210
OV_CiscoBoard Namespace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212LinkDown and Syslog Down Events with Board Down Events . . . . . . . . . . . . . . . . 212LinkDown and Syslog Down Events with Syslog Board Down Events . . . . . . . . . . 213Board Down and Syslog Board Down Events Correlator . . . . . . . . . . . . . . . . . . . . . 214
OV_PollerBoardDown Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Board Down Events with APA Board Failure Alarms . . . . . . . . . . . . . . . . . . . . . . . 216Syslog Board Down Events with APA Board Failure Alarms . . . . . . . . . . . . . . . . . 217
OV_PollerTrigger Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219APA Poll Trigger Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
OV_PollerTriggerCorr Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224OSPF Adjacency Change Events with APA Root Cause Alarms . . . . . . . . . . . . . . . 224HSRP State Change Events with HSRP Root Cause Alarms . . . . . . . . . . . . . . . . . 225Restart-Type Events with APA Node Status Alarms . . . . . . . . . . . . . . . . . . . . . . . . 225
OV_PollerPortAgg Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227LinkDown Events and Syslog Down Events with APA Aggregated Port Alarms . . 227Syslog Port Aggregation Events with APA Aggregated Port Alarms . . . . . . . . . . . 228
Setting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Disabling APA Correlators and Correlator Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Disabling a Correlator from the Correlator Store. . . . . . . . . . . . . . . . . . . . . . . . . . . 232Disabling Groups of Correlators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
8. The Advanced Routing Smart Plug-inWhat the Advanced Routing Smart Plug-in Discovers . . . . . . . . . . . . . . . . . . . . . . . . 238
Discovering HSRP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Discovering OSPF Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Discovering IPv6 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Running IPv6 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Troubleshooting IPv6 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Properly Displaying Routers not Supporting IPv6 MIBs . . . . . . . . . . . . . . . . . . . . . 243Properly Displaying IPv6 Nodes with Multiple Addresses . . . . . . . . . . . . . . . . . . . 244Viewing IPv6 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
8
Contents
Understanding IPv6 Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Supported Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Running OSPF Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Troubleshooting OSPF Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Using the OSPF View to Review Network Configurations. . . . . . . . . . . . . . . . . . . . 254
Running HSRP Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Checking NNM for Correct Handling of HSRP Virtual IP Addresses . . . . . . . . . . 257HSRP Discovery with Pre-existing NNM Topology . . . . . . . . . . . . . . . . . . . . . . . . . 258Validating Your Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Using the HSRP View to Diagnose Network Problems . . . . . . . . . . . . . . . . . . . . . . 263
For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
9. Diagnosing Network Problems with Extended TopologyViewing Extended Topology and NNM Views Using the NNM Alarm Browser . . . . 266
Using the Neighbor View to Diagnose Network Problems. . . . . . . . . . . . . . . . . . . . 266Using the VLAN View to Diagnose Network Problems . . . . . . . . . . . . . . . . . . . . . . 268
Launching Specific Views or URLs from Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Calculating Detailed Layer 2 and Layer 3 Information for ECS. . . . . . . . . . . . . . . . . 274
10. Maintaining Extended TopologyMaintaining Extended Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Checking for Extended Topology Patch Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Backing Up Extended Topology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Obtaining Supported Device Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Troubleshooting Extended Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Troubleshooting Extended Topology Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
A. Common Zone Configuration ExamplesCampus Environment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283General guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Specific guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Possibility 1: Core Devices are Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Possibility 2: Core Devices are Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
B. Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Prediscovery Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
9
Contents
Discovery Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296Post Discovery Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
C. Modifying Connections with the Connection EditorAn Overview of the Connection Editor Functionality . . . . . . . . . . . . . . . . . . . . . . . . . 302Using the Connection Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
The connectionEdits File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Using OQL Inserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304OQL Insert Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Helpful Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Practical Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309Other Limitations and Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
D. Controlling Log FilesTypes of Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318Controlling the Size of Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Switching Logging Off and On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
10
SupportPlease 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 ExtendedTopology Functionality
Chapter 1 13
Introduction to Extended Topology FunctionalityIntroducing the Extended Topology Functionality
Introducing the Extended TopologyFunctionalityHP OpenView Network Node Manager Advanced Edition’s ExtendedTopology functionality (Extended Topology) discovers layer 2 deviceinformation and displays device connectivity. HP OpenView NetworkNode Manager Advanced Edition (NNM) is a software application thatdiscovers and monitors your IP network. See Managing Your Networkwith HP OpenView Network Node Manager for more information aboutNNM.
NOTE This manual references other information sources when more detailedinformation is available. For example, Managing Your Network with HPOpenView Network Node Manager and the HP OpenView web onlinehelp are two important information sources referenced throughout thismanual.
Extended Topology discovers and displays additional device connectivityinformation 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 MIBscontained in discovered devices. For information about which devicesExtended Topology supports, see “Obtaining Supported DeviceInformation” on page 276.
Dynamic Views describes the family of browser-based views whosecontent is created as a result of choices you make when you launch theview, and which continue to provide the most current status informationavailable.
Extended Topology presents detailed layer 2 network information inseveral Dynamic Views: NNM Node view and NNM Neighbor view.Extended Topology presents ATM information in NNM Node view andNeighbor view and presents VLAN information in a VLAN view and inNNM Path view.
Chapter 114
Introduction to Extended Topology FunctionalityIntroducing the Extended Topology Functionality
See the VLAN View section of the HP OpenView web online help for moreinformation.
Extended Topology discovers and monitors network domains that useoverlapping private IP addresses. SeeChapter 3, “ConfiguringOverlapping Address Domain Discovery,” on page 41 for moreinformation.
Extended Topology and the NNM EnvironmentVariables
NNM manuals use directory path names that are independent of theunderlying file structure of the operating system you are using. For eachNNM directory, a single path name is used rather than multiple pathnames that vary by system. For example, the path name for the NNM logfile 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 nameconvention as the NNM manuals and refers to universal path namesthroughout the manual. For example, the path name for thesetupExtTopo.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. SeeManaging Your Network with HP OpenView Network Node Manager fordetails on environment variables and how to set them up for yourenvironment.
Extended Topology and the Web Browser
Extended Topology views are similar to NNM’s Dynamic Views, such asNode 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 aboutsupported web browsers and JPI versions see “SupportedConfigurations” in the Release Notes.
Chapter 1 15
Introduction to Extended Topology FunctionalityIntroducing the Extended Topology Functionality
If the Extended Topology installation program can’t find a web browseron a UNIX host system, it allows the installer to specify the web browserlocation. This is the browser that launches the NNM web interface andExtended Topology views. Edit the following file if you want to changethe 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.confmanpage).
Before you can access Extended Topology views, you must wait for acomplete Extended Topology discovery to occur. For information aboutrunning Extended Topology Discovery, see “Running Extended TopologyDiscovery” on page 23.
Accessing Dynamic Views
After Extended Topology completes a discovery, you can access theVLANs view, Node view, Path view, and Neighbor view in the followingways:
• 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 onpage 17 for an example of Home Base. In addition to launching viewsfrom Home Base, you can select tabs that cause Home Base to displayadditional information about your network. You can access Home Basefrom your browser using the following URL:
http://hostname:7510
Chapter 116
Introduction to Extended Topology FunctionalityIntroducing the Extended Topology Functionality
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 theViews menu.
NOTE Dynamic Views launched from Home Base contain tools such as Pingand Trace Route that originate from the browser’s system, not themanagement station. Access controls and security restrictions are basedon the rules that apply to the system and user of the browser.
Chapter 1 17
Introduction to Extended Topology FunctionalityIntroducing the Extended Topology Functionality
You can configure the Alarm Browser to access any view or URL from aspecific event. You cannot configure the web-based Alarm Browser toaccess any view or URL from a specific event. See “Launching SpecificViews 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 (orthe UNIX manpage) for more information.
Obtaining More Information about ExtendedTopology
You can view information from the HP OpenView web online help in thefollowing way:
• To view the HP OpenView web online help, select the ? icon (seeFigure 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 theInteracting with Views section of the HP OpenView web online help.
• There are several visual cues that give you more information aboutDynamic Views. See the Using Visual Cues in Views section of theHP OpenView web online help.
You can view the Using Extended Topology manual and the NNMRelease Notes in the following ways:
• View the NNM Release Notes from NNM: Help->NNM->ReleaseNotes.
• View this manual from NNM: Help->Online Manuals->UsingExtended Topology.
Chapter 118
2 Extended Topology Discovery
Chapter 2 19
Extended Topology DiscoveryThe Basics of Extended Topology Discovery
The Basics of Extended Topology DiscoveryExtended Topology layer 2, VLAN, ATM, and overlapping addressdomain (OAD) discovery is different from NNM discovery. Rather thanincrementally discovering new nodes over time, you configure ExtendedTopology to periodically discover network information. See “Configuringthe Extended Topology Discovery Process” on page 36 for moreinformation.
In contrast, when you first install NNM and start the NNM backgroundprocesses, all IP and layer 2 devices (devices that support bridge,repeater, and MAU MIBs) on your network are automatically discoveredand mapped out. The discovery and mapping process may take severalhours, 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 enableExtended Topology before the initial Extended Topology discovery willstart. In a very large environment, Extended Topology discovery can takeup to several hours. Completing a good NNM discovery prior to enablingExtended Topology can reduce the discovery time. See Managing YourNetwork with HP OpenView Network Node Manager for moreinformation about NNM discovery.
In larger environments, Extended Topology divides your IPv4 networkinto discovery zones to reduce the amount of time to complete anExtended Topology discovery. See “Running Extended TopologyDiscovery” on page 23 for more information about configuring zones.
NOTE Extended Topology collects detailed information from devices whoseexistence was discovered by NNM. Extended Topology collects thisinformation from specific MIBs contained in discovered devices. Forinformation about which devices Extended Topology supports, see“Obtaining Supported Device Information” on page 276.
Chapter 220
Extended Topology DiscoveryThe Basics of Extended Topology Discovery
What Extended Topology Discovers
Extended Topology discovers information about layer 2 deviceinterconnections, VLANs, and ATM connectivity. You can configureExtended Topology to monitor network domains that use overlappingprivate IP addresses.
Discovering Layer 2 Information
Extended Topology discovers layer 2 connection information and usesthis information to map managed nodes and their neighboring portrelationships. The result is a more accurate view of your network.
Discovering VLAN Information
Extended Topology discovers and displays VLAN information frommanaged devices. See “Accessing Dynamic Views” on page 16 or the HPOpenView web online help for more information on how to view thisinformation from the Extended Topology user interface.
Discovering Board and Port Information on Cisco Devices
Extended Topology discovers and displays Cisco board and portinformation 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 ofNNM’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 atrunk or port aggregation, depending on the vendor and technology used.
For example, Cisco Systems, Inc., uses the term port aggregation formultiple links that act as one logical link. In addition, Cisco uses theterm trunk to mean a single link between two switches or switch-routersthat carries the traffic of multiple VLANs.
Extended Topology discovers and displays this information as anaggregated-ports symbol (circle with internal lines) for Cisco devices, orredundant links symbol (circle with internal diamond) for other devices.
Chapter 2 21
Extended Topology DiscoveryThe Basics of Extended Topology Discovery
Discovering ATM information
Extended Topology discovers ATM information such as Virtual PathIdentifier (VPI) and Virtual Channel Identifier (VCI). You can view thisinformation by resting your mouse pointer over an interface thatsupports ATM.
Discovering Overlapping Address Domain Information
Extended Topology can monitor multiple network domains that containoverlapping addresses from the private internet address space. Thissituation occurs when you manage multiple private IP address domainsfrom outside of their gateways, and some of the addresses overlap. Beforeyou can use the Extended Topology component to manage youroverlapping IP addresses, you need to provide it with some additionalinformation. See Chapter 3, “Configuring Overlapping Address DomainDiscovery,” on page 41 for more information.
Discovering and Distributing Extended Topology Information
Extended Topology only discovers information from locally managednodes and does not pass Extended Topology information from a collectionstation to a management station. To open Dynamic Views that includeinformation from the extended topology, you need to point your webbrowsers to an object’s primary collection station.
Chapter 222
Extended Topology DiscoveryRunning Extended Topology Discovery
Running Extended Topology DiscoveryAfter you install Extended Topology, you must run the following script toenable 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 decideswhat information it needs to discover.
• It checks the system kernel parameters and tells you if you need tomake any system modifications.
• It asks you whether you want to discover information about certainprotocols.
• It asks you to set up your initial Dynamic Views password. It isrecommended that you do not use the root or Administratorpassword, as that could grant excessive authority to the person whois 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 byNNM into smaller discovery zones. See “Automatic ZoneConfiguration” on page 24 for more information.
Zone-based discovery consumes fewer computer resources, resulting inpotentially much faster network discovery. Zones can be thought of as"islands of connectivity", which are discovered independently and laterbrought together through their edge connections.
When possible, Extended Topology immediately proceeds with its firstdiscovery without recommending zone configuration.
Chapter 2 23
Extended Topology DiscoveryRunning Extended Topology Discovery
Automatic Zone Configuration
When you run the setupExtTopo.ovpl script, Extended Topologydetermines the need for using discovery zones, and can automaticallyconfigure these zones for larger environments. If you choose to haveExtended Topology configure these zones for you, make sure you followthe displayed instructions carefully.
Use the following procedure to have Extended Topology automaticallyconfigure your zones. This procedure also tells you how to test the zonesprior to running your first discovery:
1. Open the Configure Extended Topology GUI using the NNMOptions: Extended Topology Configuration menu or select theDiscovery Status tab from Home Base, then select [ExtendedTopology Configuration].
2. Select the Discovery Zones tab.
3. If you already ran the setupExtTopo.ovpl script and askedExtended Topology to automatically configure zones for you, do notreconfigure your zones at this time. However, test your zones prior tostarting a discovery. If you want Extended Topology to automaticallyconfigure zones for you, select [Configure Zones Automatically].
4. Select [Test All Zones] to test all of the zones, display anywarnings, and view any suggested remedies. If necessary, manuallyreconfigure 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 FullDiscovery 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 progressor another etrestart.ovpl script that was executed earlier, unlessyou use the etrestart.ovpl -force script. See the etrestart.ovplreference page (or the UNIX manpage) for more information.
Chapter 224
Extended Topology DiscoveryRunning Extended Topology Discovery
NOTE Once you run the setupExtTopo.ovpl script, you can have ExtendedTopology automatically configure discovery zones at your request. Usethis automatic zone configuration feature only after completing asuccessful NNM discovery.
If you request that Extended Topology configure zones automatically at alater time, you will overwrite any existing zone configurationinformation. To automatically configure your zones, use the followingprocedure:
1. From Home Base, select the Discovery Status tab.
2. Select [Extended Topology Configuration].
3. Select the Discovery Zones tab.
4. Select [Configure Zones Automatically] and follow theinstructions.
5. Once Extended Topology completes the automatic configurationprocess, it displays any warning messages. You can also select [TestAll Zones] to test all of the zones, display any warnings, and viewany suggested remedies. If necessary, manually reconfigure the newzones 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, youmay 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 anexisting zone if the IP address matches one of the zone’s subnetwildcards. Use the following techniques to decide if Extended Topologyplaced nodes into incorrect zones:
• Check the output for nodes that incorrectly appear in the defaultzone by using the following procedure:
Chapter 2 25
Extended Topology DiscoveryRunning Extended Topology Discovery
1. Open the Configure Extended Topology GUI using the NNMOptions: Extended Topology Configuration menu or selectthe Discovery Status tab from Home Base, then select[Extended Topology Configuration].
2. Select the Discovery Zones tab.
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 intothe right zones or run another automatic zone configuration. “ManuallyConfiguring Zones,” for more information.
Manually Configuring Zones
In most cases, Extended Topology configures zones for you. However, incertain circumstances you may want to manually adjust your zoneconfiguration to try and reduce Extended Topology’s discovery time.
There is another reason you may want to manually adjust your zoneconfiguration. Suppose Extended Topology displayed warnings when youselected [Test All Zones]. To remedy these warnings, you may need tomanually adjust the zone configuration.
A good strategy for defining zones is to categorize your network devicesby geography, such as by city, state, or building.
NOTE When defining your zones, do not separate switches that are directlyconnected together within a subnet.
To manually organize your devices into zones, use the followingprocedure:
1. Open the Configure Extended Topology GUI using the NNMOptions: Extended Topology Configuration menu or select theDiscovery Status tab from Home Base, then select [ExtendedTopology Configuration].
2. Select the Discovery Zones tab.
Chapter 226
Extended Topology DiscoveryRunning Extended Topology Discovery
3. Organize your devices into zones. You may need to calibrate yourzones as outlined in this procedure. See Appendix A, “Common ZoneConfiguration Examples,” on page 281 for more information.
• Organize zones with fewer nodes when these nodes contain manyinterfaces. An example of this would be a network that contains ahigh quantity of switches housing many ports.
• Organize zones with more nodes when these nodes contain fewerinterfaces. An example of this would be a network that contains alow quantity of switches housing few ports.
4. You can limit Extended Topology discovery to only those devices youspecify in zones. To do this, select the check box that excludes nodesthat are not included in any of the zones you configure.
NOTE When the Extended Topology discovery process begins, NNMtransfers its node information to Extended Topology. ExtendedTopology includes these nodes in its discovery process. If you assignnodes to discovery zones, there may be a subset of the nodestransferred from NNM that aren’t included in any zone. ExtendedTopology automatically assigns these remaining nodes to a defaultzone. Select this check box to stop Extended Topology fromdiscovering these nodes.
You can also limit your discovery with the bridge.noDiscover file.Devices specified there are not discovered regardless of how youconfigure your zones. See “Limiting Extended Topology Discovery” onpage 32 for more information.
5. In the Zone:Administration text box you can specify any hostnamethat your DNS server can resolve to an IP address, or directly specifyany node’s IP address. Separate entries with a semicolon. You canalso use the following wildcard symbols:
• Asterisk: Use an asterisk to represent any number of charactersup 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
Extended Topology DiscoveryRunning Extended Topology Discovery
*.* 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, butdoes 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 arange, or characters not within a range:
[bcf]an.corp.com matches ban.corp.com, can.corp.com, orfan.corp.com, but does not match dan.corp.com orlan.corp.com.
[b-d]an.corp.com matches ban.corp.com, can.corp.com, ordan.corp.com, but does not match fan.corp.com, an.corp.com, orclan.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 CurrentZones area of the Extended Topology Configuration screen.Select a zone, then select [Add to Zone] to add more addresses to aspecific zone. You can also use [Delete] and [Replace] to help youmanage your zones.
7. Select [Test All Zones] to test your zones. This test will checkyour zone configuration and may recommend configuration changes.
8. Select [Apply] to save your changes.
9. Once these zones are successfully configured, select [Initiate FullDiscovery Now] or execute, as Administrator or root, the followingscript to start a discovery:
• Windows:%OV_BIN%\etrestart.ovpl
• UNIX: $OV_BIN/etrestart.ovpl
Chapter 228
Extended Topology DiscoveryRunning Extended Topology Discovery
NOTE After you move devices between or among zones, you should initiatea full Extended Topology discovery. If you add new devices to ordelete devices from a single zone, you can save time by initiating anExtended Topology discovery on that single zone.
10. You can check the amount of time Extended Topology spendsdiscovering your zones by running the ovstatus -v ovet_discocommand. If the discovery time of any of your zones is abnormallylong when compared to that of other zones, do one or both of thefollowing:
• Add a new zone and move some of the devices from the problemzone into the new zone.
• Move some of the devices from the problem zone into one or moreof the existing zones that are being discovered faster.
Once these zones are successfully configured, select [Initiate FullDiscovery Now] or execute, as Administrator or root, theetrestart.ovpl script to start a new Extended Topology discovery.
NOTE Once Extended Topology completes a discovery with the new zoneconfiguration, you should check the discovery results to make sure yourzones are configured correctly. See “Verifying and Modifying Your ZoneConfiguration” on page 25.
Transferring Information from NNM to ExtendedTopology
Extended Topology uses NNM data to speed up discovery. When a newdiscovery begins, Extended Topology starts background processes thatretrieve data from NNM about the devices NNM is actively managing.Extended Topology discovers information from these devices if theyrespond to SNMP requests.
For a device not responding to SNMP requests, Extended Topologycreates a node and a local interface for that node using NNM data. Thisnode appears in the Extended Topology views, but may contain anincomplete set of attributes and connectivity. To identify an unresponsive
Chapter 2 29
Extended Topology DiscoveryRunning Extended Topology Discovery
node, move your mouse over the node in one of the Extended Topologyviews. Extended Topology will display a message about SNMP accessproblems with the node.
To enable Extended Topology, run the following script and follow theinstructions:
• Windows: %OV_BIN%\setupExtTopo.ovpl
• UNIX: $OV_BIN/setupExtTopo.ovpl
After you enable Extended Topology with the setupExtTopo.ovplscript, you will only need to run this command again if you want toenable or disable certain protocols. For more information about thesetupExtTopo.ovpl script, see the setupExtTopo.ovpl reference page inNNM’s online help (or the UNIX manpage.
The following information is copied from NNM to Extended Topology andused by several Extended Topology processes. See Figure 2-1 on page 31for a graphical illustration.
• NNM IP address and hostname information.
• NNM ARP cache information.
• NNM SNMP community string information.For more informationabout NNM and Extended Topology community names, see theovsnmp.conf_db reference page in NNM’s online help (or the UNIXmanpage).
• NNM SNMP port information.
NOTE Extended Topology uses the information it receives from NNM tocalculate the number of nodes it may discover. Extended Topologynotifies you when the number of discovered nodes exceeds the number ofnodes it is licensed for. Extended Topology may discover additionalinterfaces after receiving information from NNM, however it does notcount these interfaces as discovered nodes for licensing purposes.
Use the Options:Configuration-->SNMP Configuration menu tochange device community string information in NNM. ExtendedTopology applies SNMP community string configuration changes during
Chapter 230
Extended Topology DiscoveryRunning Extended Topology Discovery
the next discovery cycle. For more information about changing devicecommunity string information, see the xnmsnmpconf reference page inNNM’s online help (or the UNIX manpage).
If you need Extended Topology to apply new SNMP community stringchanges immediately and run a new Extended Topology discovery, go toHome 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 torun a new Extended Topology discovery:
• Windows: %OV_BIN%\etrestart.ovpl
• UNIX: $OV_BIN/etrestart.ovpl
For more information about the etrestart.ovpl script, see theetrestart.ovpl reference page in NNM’s online help (or the UNIXmanpage).
Figure 2-1 NNM to Extended Topology Information Transfer
NNM automaticallydiscovers and storesdevice information
NNM seeds theExtended Topologyperiodic discovery
NNM databases
Extended Topologyreceives host, ARP,community name, andSNMP port information
setupExtTopo.ovpl
NNMinformation
script startsinformation transferto Extended Topology
from NNM.
Chapter 2 31
Extended Topology DiscoveryRunning Extended Topology Discovery
Limiting Extended Topology Discovery
You can exclude devices from Extended Topology discovery by creatingan Extended Topology Discovery Exclusion List.
Creating the Extended Topology Discovery Exclusion List
Extended Topology limits the breadth of discovery according to thecontents 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 thebridge.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 excludedby Extended Topology discovery. Enter one NNM filter name, IPaddress or wildcard per line.
3. Run a new Extended Topology discovery.
For more information about the Extended Topology Discovery ExclusionList and the bridge.noDiscover file, see the bridge.noDiscoverreference page in NNM’s online help (or the UNIX manpage).
Setting up Dynamic View Security
During Extended Topology setup, you were prompted to enter anAdministrator login and password. To configure additional user roles andpasswords, edit the following file:
Chapter 232
Extended Topology DiscoveryRunning Extended Topology Discovery
• 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 cancreate an operator role that has access to all of the Dynamic Views, butcannot access any of the configuration tools. See theDynamicViewsUsers.xml reference page in NNM’s online help (or theUNIX manpage) for more information.
If non-ASCII characters are added to XML files, you must preserve theUTF-8 codeset for these characters.
NOTE The Windows Notepad editor allows files to be saved in the UTF-8 codeset. On many UNIX platforms, the iconv command can be used totranslate from Shift JIS (or any other code set) into UTF-8 to makeediting in a non-UTF-8 codeset simpler.
For more detailed information on setting up passwords, including how touse MD5 encryption, look for additional instructions contained in thefollowing 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 discoverybefore using Extended Topology views. To view Extended Topologydiscovery status, use the following procedure:
1. Point your browser to Home Base
2. Select the Discovery Status tab
The discovery status is normally updated quite often, but there can belong periods, potentially many hours, where the progress bar does notchange. This is due to the duration of some processing steps and the wayprogress is measured. It does not reflect a problem with discovery.
Chapter 2 33
Extended Topology DiscoveryRunning Extended Topology Discovery
While Extended Topology discovery is in progress, the activity indicatormoves to indicate that everything is proceeding normally. The activityindicator usually moves every few seconds, but you should keep in mindthat it may pause during lengthy internal operations. Ordinarily, a pauseof this kind will be fifteen minutes or less.
However, if the activity indicator is stationary for too long, such as anhour or more, Extended Topology discovery may have stalled. You canuse the discovery status time stamp in the text area to find the time ofthe most recent update.
You can use the following command to display the statuses of each of theExtended Topology discovery processes.
• Windows: %OV_BIN%\ovstatus -c
• UNIX: $OV_BIN/ovstatus -c
Many Extended Topology processes only run during discovery. AfterExtended Topology completes its discovery, these processesautomatically exit. The following process status output shows the outputof 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, andbegins another discovery, when it reaches or exceeds its discoverythresholds. You can use the Extended Topology Configuration GUI tomodify these discovery thresholds. To open the Extended TopologyConfiguration GUI, use the NNM Options: Extended TopologyConfiguration menu or select the Discovery Status tab from HomeBase, then select the Configure Topology tab.
For more information about troubleshooting Extended Topologydiscovery, see “Troubleshooting Extended Topology Discovery” onpage 277.
Understanding Recurring Discovery
The Extended Topology model of recurring discovery differs from thecontinuous discovery present in NNM. Extended Topology captures dataabout your network as it exists during the most recent discovery cycle, orthe most recent previous discovery cycles. It does not update the databetween discovery cycles.
Chapter 234
Extended Topology DiscoveryRunning Extended Topology Discovery
This means that only the layer 2 connections that exist during ExtendedTopology discoveries get recorded. In addition, device information (suchas VLAN, port aggregation, and ATM data) is gathered only from devicesthat are accessible during the Extended Topology discoveries. An“accessible” device responds to SNMP requests from NNM. For this tohappen, NNM must be configured to use the correct SNMPGET-Community name for the device.
Situations may arise that prevent a previously discovered device fromresponding with device information during later discovery cycles. Whena situation like this arises, Extended Topology retains data about thepreviously discovered, but unresponsive device for recent discoverycycles.
In contrast, suppose a specific device becomes unresponsive, andcontinues to be unresponsive during several consecutive discovery cycles.The device and its information are no longer shown in NNM’s DynamicViews.
Post-discovery changes in the network are not dynamically reflected inthe data that Extended Topology provides. They instead get incorporatedduring 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 Topologydiscoveries, but responded with device information during the mostrecent discovery cycle, a VLAN view will display VLAN informationfor it.
• If a device became inaccessible during some past Extended Topologydiscovery, and continued to be unresponsive during severalconsecutive discovery cycles, a VLAN view will not display the deviceor VLAN information about the device.
• A Neighbor view will omit a neighboring device that happened to beinaccessible during several consecutive discovery cycles.
This list is not comprehensive, but gives you a sense of how periodicdiscovery can affect the data you observe later.
You can modify Extended Topology’s default discovery options to meetyour specific needs using information from this list. See “Configuring theExtended Topology Discovery Process” on page 36 for more information.
Chapter 2 35
Extended Topology DiscoveryRunning Extended Topology Discovery
Configuring Extended Topology Discovery
In smaller environments, Extended Topology begins discovering networkinformation after you run the setupExtTopo.ovpl script. ExtendedTopology defaults to running a discovery once a default number of NNMtopology changes occur.
Configuring the Extended Topology Discovery Process
To modify Extended Topology discovery options, use the NNM menuOptions:Extended Topology Configuration or select the DiscoveryStatus tab from Home Base, then select the Configure ExtendedTopology tab. You have several configuration options. You can configureExtended Topology discovery behavior if you select the DiscoveryBehavior 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 topologychanges. The number of topology changes includes layer 3 discoveryinformation from NNM.
• Schedule a new discovery daily or weekly.
• Immediately begin a new discovery by selecting [Initiate FullDiscovery Now].
Make sure you select [Apply]to save your changes.
NOTE Suppose you configure Extended Topology to initiate a new discoveryevery time Extended Topology is restarted. Then every time you run, asAdministrator or root, the following command, it initiates a newExtended Topology discovery.
• Windows: %OV_BIN%\ovstart
• UNIX: $OV_BIN/ovstart
Use caution when using the ovstart command, as it restarts all NNM andExtended Topology processes. For more information about the ovstartcommand, see the ovstart reference page in NNM’s online help (or theUNIX manpage).
Chapter 236
Extended Topology DiscoveryRunning Extended Topology Discovery
After modifying Extended Topology discovery options, you can applythese modifications and start a new discovery by doing one of thefollowing 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.
1. Select the Discovery Status tab
2. Select [Extended Topology Configuration]
3. Select [Initiate Full Discovery Now]
• If you add new devices to a specific zone, complete the followingprocedure:
1. Go to Home Base
2. Select the Discovery Status tab
3. Select [Extended Topology Configuration]
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 newdiscovery, but only on the devices in one specific zone. This is useful ifyou have added or deleted nodes in that one zone. However, if you knowof changes in multiple zones (such as when you have relocated a nodefrom one zone to another), you should run a full discovery.
You can display the process statuses by executing the followingcommand:
• Windows: %OV_BIN%\ovstatus -c
• UNIX: $OV_BIN/ovstatus -c
Chapter 2 37
Extended Topology DiscoveryRunning Extended Topology Discovery
If you restart Extended Topology processes and you do not haveExtended Topology configured to run a new discovery every time yourestart 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 fordiscovery processes. A new discovery does not occur until ExtendedTopology meets the discovery configuration parameters you set in theExtended Topology Configuration GUI, you select [Initiate FullDiscovery Now], or you execute, as Administrator or root, theetrestart.ovpl script.
For more information about the etrestart.ovpl script, see theetrestart.ovpl reference page (or the UNIX manpage). For moreinformation about Extended Topology configuration see the HPOpenView 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 fulldiscovery.
Suppose you add new devices to a single zone. You can save time byinitiating an Extended Topology discovery on that single zone. To do this,follow these instructions:
1. From Home Base, select the Discovery Status tab.
2. Select [Extended Topology Configuration].
3. Select the Discovery Zones tab. If you configured OverlappingAddress Domains, you can also select the Overlapping AddressDomain 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.
Chapter 238
Extended Topology DiscoveryRunning Extended Topology Discovery
NOTE The [Discover Zones] button causes Extended Topology to run a newdiscovery, but only on the devices in one specific zone. This is useful ifyou have added or deleted nodes in that one zone. However, if you knowof changes in multiple zones (such as when you have relocated a nodefrom one zone to another), you should run a full discovery.
After you initiate your discovery, you can monitor the status of yourdiscovery. See “Viewing Discovery Status” on page 33 for moreinformation.
Chapter 2 39
Extended Topology DiscoveryRunning Extended Topology Discovery
Chapter 240
3 Configuring OverlappingAddress Domain Discovery
Chapter 3 41
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
Discovering and Monitoring Nodes by usingOverlapping Address DomainsThe need to conserve IPv4 addresses led to the development anddeployment of IP addresses in the private internet address space. Tounderstand details about the private internet address space, seeRFC1918.
As the use of the private address space increased, so did demand forInternet access to computers configured with private IP addresses. Staticnetwork address translation (or, "static NAT") was developed to answerthis demand. Static NAT takes place on the gateway between the privateaddress domain and the Internet. A gateway configured with static NATmaps public IP addresses (or, "management IP addresses") to computersin the private address domain. Those computers, still configured withprivate IP addresses, are then directly accessible over the Internet viathe static NAT gateway.
When using NNM to manage multiple domains that use private IPaddresses, it often discovers duplicate private IP addresses.You need touse the Extended Topology features of NNM Advanced Edition tomanage network domains that have overlapping private internetaddresses.
You can use Extended Topology to distinguish these overlappingaddresses by configuring each address group into an OAD (overlappingaddress domain). A single OAD is a set of IPv4 addresses that are static,do not overlap, and are directly routable without manipulation of theIPv4 header.
Figure 3-1 on page 43 shows an example of Extended Topology managingtwo private address domains from a point outside either one. Supposethe IP addresses in OAD A and OAD B overlap. You can configureExtended Topology to differentiate addresses from the two overlappingaddress domains.
If there is a firewall between the NNM management station and anynodes tied to a specific OAD, you must configure this firewall to passICMP (port 7), SNMP (port 161), and SNMPTRAP (port 162) packetsbetween the management station and the managed nodes. If you want tolog on to any OAD nodes (telnet) using Dynamic Views from themanagement station, you will need to open port 23 as well. This minimal
Chapter 342
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
relaxation of the firewall is required to support network managementthrough it. By restricting the communications to the managementstation only, there is virtually no loss of security.
Figure 3-1 Overlapping Address Domains
Configuring Extended Topology to Discover andMonitor Overlapping Private Internet Addresses
Before you can use Extended Topology to monitor your overlappingprivate IP addresses, you need to provide the information discussedbelow.
Providing Extended Topology with OAD Information
A key concept of monitoring overlapping private IP addresses isunderstanding the OAD. The OAD denotes a set of unique, private IPaddresses. For example an OAD might represent the private IPaddresses of a small business, specific department, or a specificworkgroup in a large company.
1. For each OAD that you define, you need to create a separatedirectory beneath the following directory:
OAD A OAD B
Gateway A Gateway B
Network
NNM ManagementStation (ExtendedTopology Functionality)
Chapter 3 43
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
• Windows: %OV_CONF%\nnmet\dupip
• UNIX: $OV_CONF/nnmet/dupip
There is no specific naming convention, so you can choose a friendlyname for each directory. As an example, suppose you have a group ofprivate IP addresses in an OAD for a store called My Shop. Youwould 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 needto create a dupip.conf file and add commands to this file that definethe 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 howto 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 nameddupip.seed. This file lists the IP addresses (required) and nodenames (optional) that you wish to manage for this OAD. Add the IPaddresses in the first column and the optional node names in thesecond column. Enter one IP address and node name per line asdescribed in the dupip.conf file.
IMPORTANT Do not add the virtual IP address of an HSRP group to thedupip.seed file.
NOTE Your name resolution scheme must be able to resolve each nodename 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 yourname resolution scheme.
Chapter 344
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
The seed file defines the discovery zone for the OAD, which appearsin the Overlapping Address Domains tab of the Extended Topologyconfiguration interface.
In this example, you would create the following file containing yourprivate 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 shouldrun the ovdupip command to make sure your file entries aresyntactically correct. If there are errors in the files, this tool will tellyou what is wrong, and where to look to remedy the problem. See theovdupip 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 theovdupip command each time you modify one of your existingdupip.conf files or add new dupip.conf files.
5. Go to the Extended Topology Configuration web page. You canget 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 aboutaccessing 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 ExtendedTopology determines your changes are free of errors, it creates a zonefor every defined OAD. These changes or additions will affect thenext discovery cycle.
8. To immediately initiate a complete discovery of all zones, execute, asAdministrator or root, the etrestart.ovpl command. You canalso select [Initiate Full Discovery Now] from the DiscoveryBehavior tab located in the Extended Topology Configurationmenu.
Chapter 3 45
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
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 onthat single zone.To initiate a discovery cycle for a specific zone, usethe 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 todiscover.
e. Select [Discover Zone].
Deleting a Single OAD Zone You can remove information about asingle OAD zone without having to rediscover all of the other zones. Todo this, use the following procedure:
1. Go to the Extended Topology Configuration web page. You canget there from Home Base by selecting the Discovery Status tab,then selecting [Extended Topology Configuration].
2. From Home Base, select the Discovery Status tab.
3. Select [Extended Topology Configuration].
4. Select the Overlapping Address Domains tab.
5. Select the option button to the left of the OAD zone you want todelete.
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 aNAT (Network Address Translation) device.
Chapter 346
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
Devices on the left side of the NAT device are in OAD 0. Devices on theright side of the NAT are in a non-zero OAD Domain (OAD 7 inFigure 3-2) and may correspond to a specific ISP customer. The OADconfiguration uses the term Gateway to identify the NAT device. Inaddition, there can be more than one Gateway per OAD.
Figure 3-2 Typical OAD Environment
Although the management station communicates to devices in OAD 0using the non-translated private addresses, it communicates to devicesin the other OAD (OAD 7) using the translated private addresses. This ispossible because the NAT device translates a subset of the privateaddresses to the corresponding public translated addresses.
You can add entries to the $OV_CONF/nnmet/dupip/domain/dupip.seedconfiguration file, specifying one address per device to be used as thetranslated public management address for the device. Although otheraddresses may be translated by the NAT, Extended Topology will usethis 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 managementadministrator and can be any string that is a valid directory name.
When deciding which address on a specific device to have ExtendedTopology translate and use as the management address, it is goodpractice to select the most upstream address, or to use the device’sloopback address. Whenever possible, select an address that is available
NotDiscovered
MS NATA R N GB
C
D
F H E
Gateway
OAD 0OAD 7
Chapter 3 47
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
on an interface closest to the management station. This will facilitatebetter analysis because partial failures on the device will still allow themanagement station to talk to the device.
OAD and Undiscovered NAT Devices Although Extended Topologyuses the functionality of the NAT device for discovery and monitoring, itmay not actually discover the NAT device. For example, organizationsfrequently deploy NAT devices for security or to isolate different parts ofthe network. If these NAT devices do not respond to MIB-2 SNMPqueries, Extended Topology does not discover them. As a result, the NATdevice may not be in the extended topology or may not be connectedproperly. When a NAT device is not discovered, the connectivity from theextended topology may look more like the diagram in Figure 3-3.
Figure 3-3 Undiscovered NAT Device
Potential APA Concerns About Undiscovered NAT Devices If afailure occurs in the OAD environment, shown in Figure 3-3, APA setsstatus and emits alarms consistent with user expectations unless theentire OAD environment becomes inaccessible.
For example, suppose that device N fails. When that happens, APAconsiders all of the devices in the OAD 7 area to be in the Far-From-FaultArea as shown in Figure 3-4. In this example, APA does not generate anyalarms, and sets the status of devices in OAD 7 to unknown. Thisproblem occurs because the fault area must contain at least one device
MS A R N GB
C
D
F H E
Gateway
NotDiscovered
OAD 7OAD 0
Chapter 348
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
that is accessible via SNMP or ICMP. Since device N is not connected toany accessible upstream device, APA places device N in theFar-From-Fault Area instead of the Fault Area.
Figure 3-4 OAD Scenario: Device N Fails
A similar result occurs if the NAT device fails or the downstreaminterface of device R fails, as shown in Figure 3-5 on page 49. In eithercase, the entire OAD 7 area will be inaccessible. APA will not emit anyalarms 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 tocritical, and emits an OV_APA_IF_DOWN R alarm. See“How APA Looks atFailures” on page 94for more information.
Figure 3-5 OAD Scenario: NAT Device or Device R Interface Fails
NotDiscovered
MS NATA R GB
C
D
F H E
Normal Area
Normal Minor
Critical Unknown
N
Far-From_Fault Area (APA emits no alarms)
Not Discovered
OAD 7OAD 0
NAT
Gateway
NotDiscovered
MS NATA R GB
C
D
F H E
Gateway
OAD 0
Normal Minor
Critical Unknown
N
Not Discovered
Interface 1Down
Far-From_Fault Area (APA emits no alarms)OAD 7Fault
Area
NAT
Chapter 3 49
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
Resolving APA Concerns About Undiscovered NAT Devices Youcan do some additional configuration to help APA accurately determinethe root cause in OAD environments with undiscovered NAT devices. Todo this, you need to configure Extended Topology to recognize a devicelocated downstream from a NAT device.
The $OV_CONF/nnmet/dupip/domain/dupip.conf configuration fileprovides a mechanism, the NextHop keyword, to specify the device onehop downstream from a NAT device. In the example shown in Figure 3-6on page 51, the downstream device would be device N. If device N has anIP 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 specifythis device: NextHop IP=15.1.2.3. This downstream device issometimes referred to the egress device (router or switch).
When entering an IP address using the NextHop keyword, you mustenter the device’s public address. You cannot enter an address range orwildcard. If the NAT device maps several addresses associated with theegress router, and Extended Topology discovers these addresses, thisresults in several public addresses being associated with the egressrouter. However, there is still only one associated management address.In this situation, you must use the management address as the NextHopaddress that you add to the dupip.conf file.
NOTE When deciding which address on a specific device to have ExtendedTopology translate and use as the management address, it is goodpractice to select the most upstream address, or to use the device’sloopback address.
Chapter 350
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
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
When you specify one or more egress devices in the dupip.conf fileusing the NextHop keyword, APA will process the egress routersdifferently when they fail. For example, if an egress device fails, asshown in Figure 3-6, APA will do no further analysis on the specifiedegress device. Instead, APA will immediately report the egress device asa primary failure in the Fault Area, report the egress device status ascritical, and generate the appropriate status alarms.
The result is that for a catastrophic failure where an entire OAD area isinaccessible, only one alarm is generated that indicates the device thatfailed or a device nearby. Thus, the network operator and administratorwill see not see an alarm browser that is cluttered with alarms fromdownstream devices that are not actually critical. They do see an alarmand a graphical indicator that a significant network failure has occurred.
Suppose an interface fails on device R, as shown in Figure 3-7 onpage 52. When this occurs, APA emits the following two alarms:
• Interface Down R IfIndex 1
• Node Down N
MS NATA R GB
C
D
F H E
Gateway
N
Normal
Minor
Critical Not Discovered
NotDiscoveredNormal Area Fault
Area
Far-From_Fault Area (APA emits no alarms)
egressdevice
Unknown
NAT
OAD 0OAD 7
Chapter 3 51
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
APA sets both interface 1 and device N to a critical status, and setsdevice R to a minor status.
Figure 3-7 Interface 1 on Device R Fails
In the next example, the NAT or Gateway device is handled like theegress device, as both the NextHop and Gateway devices are identified inthe dupip.conf file. This is shown in Figure 3-8.
Figure 3-8 APA Behavior with NextHop and Gateway Devices Configured
In this configuration, suppose interface 1 on device R fails, causing anentire OAD area to be inaccessible. This down interface normallyconnects to the NAT device in OAD 0 (device R, interface 1). In thisexample, APA generates the following three alarms:
• Interface Down R IfIndex 1
• Node Down NAT
• Node Down N
MS NATA R GB
C
D
F H E
Gateway
NotDiscovered
Normal Area
NormalMinor
CriticalUnknownNot Discovered
N
Interface 1Down
FaultArea
Far-From_Fault Area (APA emits no alarms)FaultArea
NAT
OAD 0OAD 7
MS NATA R GB
C
D
F H E
Gateway
NotDiscovered
N
Far-From_Fault Area (APA emits no alarms)
NormalMinor
CriticalUnknownNot Discovered
NAT
Interface 1Down
Normal Area
FaultArea
FaultArea OAD 7
OAD 0
Chapter 352
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
APA analyzes NextHop and Gateway device failures more quickly thanother devices, and polls devices located in fault areas more quickly thandevices located in Far-From-Fault areas.
Understanding OAD View Status Information
The Active Problem Analyzer polls OAD addresses and reports devicestatus information in the OAD view. See “Using the Active ProblemAnalyzer” on page 85 for more information.
You can identify OAD alarms in the Alarm Browser, as the alarms sourcecontains an @ symbol followed by the name of the Overlapping AddressDomain. See the trapd.conf reference page in NNM’s online help (orthe UNIX manpage) for more information.
Data Collections & Thresholds
You can enable Extended Topology to collect SNMP data for nodesconfigured in an OAD. This allows you to do the following:
• Collect MIB data from network nodes automatically at regularlyscheduled 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 thefollowing 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 inthe 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
Configuring Overlapping Address Domain DiscoveryDiscovering and Monitoring Nodes by using Overlapping Address Domains
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 inventoryreports for nodes configured in an OAD.
See Managing your Network with Network Node Manager for moreinformation about Data Collection and Thresholds.
Chapter 354
4 Problem Diagnosis
Chapter 4 55
Problem DiagnosisIntroducing Problem Diagnosis Functionality
Introducing Problem Diagnosis FunctionalityProblem Diagnosis is an automated IP network path analysis tool thatpresents end-to-end path information accurately. Furthermore, ProblemDiagnosis lets you see detailed information from nodes and devices in aparticular path.
Problem Diagnosis gives NOC and IP Network Operators & Engineerstools for fast problem diagnosis and resolution in IP-based networks. Inparticular, Problem Diagnosis offers a probe-based path tool that findsand monitors the paths between itself and any reachable node that it isconfigured 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 aJava applet that interacts with the Network Node Manager server topresent network information. Like all applets, it needs noinstallation because it runs in the context of a Web browser.
The Problem Diagnosis view is simple to use and presents data ineasy-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, theintelligence behind the Problem Diagnosis functionality. Itassimilates information and responds to requests from a userrunning a Problem Diagnosis view.
The Problem Diagnosis server gets its topology data from NNM, fromProblem Diagnosis probes, and other HP OpenView applications.
Based on the topology data it mines from these sources, it canpresent several alternative ways to examine the path(s) betweennodes.
• The Problem Diagnosis Probes
Chapter 456
Problem DiagnosisIntroducing Problem Diagnosis Functionality
The Problem Diagnosis probes are key suppliers of data to theProblem Diagnosis system. Probes are independent Javaapplications that can reside on any system of your choosing (see theRelease Notes for supported platforms and versions). There is nolimit to the number of probes you can install, or the number of pathsa probe can monitor. Likewise, a probe can be used by more than oneProblem Diagnosis server.
A probe collects information about paths between itself and anydesired target. It uses a technique similar to the familiartraceroute utility, and runs periodically to test the route to thetarget(s) it is configured for. On each run, it collects data about theroute:
— Devices along the route
— Lag time between devices
— New routes to the target
When you request probe data, the Problem Diagnosis server contactsthe 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 topologydata supplied by Problem Diagnosis probes. Probes can reside on anysystem in the network, and can be configured to collect path informationto any reachable destination in the network.
Table 4-1 on page 58 provides a list of features of Problem Diagnosis aswell as limitations.
Chapter 4 57
Problem DiagnosisIntroducing Problem Diagnosis Functionality
See the online help for more details about retrieving informationcollected by Problem Diagnosis.
Table 4-1 Summary of Problem Diagnosis Features
Can Cannot
• Show a path from where theprobe resides to anyreachable destination(firewalls can make somehosts unreachable).
• Show path utilizationstatistics.
• Show current ping rates.
• Show baseline of ping rates.
• Send events to subscribers(such as HP OpenViewOperations) if a pathbecomes unreachable, pathchanges, and so on.
• Show status of hops usingping.
• Send brownout events to theevent browser indicating aperformance problem.
• Show IP-layer 2 devices(switches, hubs, bridges,and so on).
NOTE: After Problem Diagnosishas determined path data, thedestination does not have to becurrently up (or reachable) tosee the historical paths.
• Show a path from any twoarbitrary endpoints.
• Show outbound interfaces(from ping's perspective)except on the probe's host.
Chapter 458
Problem DiagnosisIntroducing Problem Diagnosis Functionality
Starting a Problem Diagnosis View
After installed and configured, Problem Diagnosis is very simple tooperate. Follow these steps:
1. Start the Problem Diagnosis server with which you will connect, if itis not already running. See “Starting and Stopping the Server” onpage 73 for instructions.
2. Start all probes for that server, if they are not already running. Itmay take a few minutes before Problem Diagnosis has access to allprobes. See“Starting and Stopping a Probe” on page 73 forinstructions.
3. Access Home Base as follows:
a. Open a Netscape or Internet Explorer browser window. See theRelease Notes for supported browser versions.
b. Enter the following URL: http://hostname:7510
NOTE Replace hostname with the actual hostname or IP address of thesystem on which NNM is installed. For example:http://robot.cnd.hp.com:7510
4. From Home Base, select Problem Diagnosis View from the Viewdrop down list and click [Launch View]. The Problem Diagnosis maindialog opens as shown in Figure 4-1.
Figure 4-1 Problem Diagnosis View
Chapter 4 59
Problem DiagnosisInstalling Remote Probes
Installing Remote ProbesAfter the installation of Network Node Manager and setup of ExtendedTopology, a Problem Diagnosis probe and server is installed on the sameNNM management station. The probe is assigned to serve that ProblemDiagnosis server.
Additional Problem Diagnosis probes can be installed throughout yournetwork on HP-UX, Solaris, or Windows operating systems of yourchoosing. Each installation of a Problem Diagnosis probe is assigned toserve one Problem Diagnosis server. For more details, see “LinkingServers 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 aremote probe, determine if one of these deployment options isappropriate for your situation. See “Linking Servers and Probes” onpage 65.
Consider installing probes in key locations in the network where theycan monitor crucial paths.
An automated installation package in the NNM distribution guides youthrough the installation process of remote probes on HP-UX, Solaris, orWindows operating systems of your choosing.
Chapter 460
Problem DiagnosisInstalling Remote Probes
Table 4-2 on page 61 outlines the procedures necessary to install aProblem Diagnosis probe.
Table 4-2 Instructions for Installing Remote Probes
Platform of ProbeSystem
Instructions
HP-UX 1. From the Problem Diagnosis server system, enter thefollowing from a command window prompt:UNIX: cd $OV_MAIN_PATH/pdAE/binWindows: %OV_MAIN_PATH%\pdAE\bin
2. FTP probeHP.tar to the system where the remote probe is tobe installed. In particular, FTP the tar file to the rootdirectory of the target probe system.
3. From the remote probe system, as user root, untarprobeHP.tar in the root directory:tar -xvf probeHP.tar
4. Enter: cd /opt/OV/bin/pdAE/bin
5. As user root, enter: ./pdpinstall.shThis installs the probe software in /opt/OV/bin/pdAE.
You are prompted for the name of the Problem Diagnosisserver with which the probe will communicate. Enter thefully-qualified DNS name of the assigned server. Forexample, to assign the probe to the Problem Diagnosis server,Minotaur, enter Minotaur.cnd.hp.com when prompted.
Chapter 4 61
Problem DiagnosisInstalling Remote Probes
Solaris 1. From the Problem Diagnosis server system, enter thefollowing from a command window prompt:UNIX: cd $OV_MAIN_PATH/pdAE/binWindows: %OV_MAIN_PATH%\pdAE\bin
2. FTP probeSUN.tar to the system where the remote probe isto be installed. In particular, FTP the tar file to the rootdirectory of the target probe system.
3. From the remote probe system, as user root, untarprobeHP.tar in the root directory:tar -xvf probeHP.tar
4. Enter: cd /opt/OV/bin/pdAE/bin
5. As user root, enter: ./pdpinstall.shThis installs the probe software in /opt/OV/bin/pdAE.
You are prompted for the name of the Problem Diagnosisserver with which the probe will communicate. Enter thefully-qualified DNS name of the assigned server. Forexample, to assign the probe to the Problem Diagnosis server,Minotaur, enter Minotaur.cnd.hp.com when prompted.
Table 4-2 Instructions for Installing Remote Probes (Continued)
Platform of ProbeSystem
Instructions
Chapter 462
Problem DiagnosisInstalling Remote Probes
The Problem Diagnosis probe starts immediately, and is configured torun automatically at system startup.
Windows 1. From the Problem Diagnosis server system, enter thefollowing from a command window prompt:UNIX: cd $OV_MAIN_PATH/pdAE/binWindows: %OV_MAIN_PATH%\pdAE\bin
2. FTP probeWIN.zip to the system where the remote probe isto be installed.
3. From the remote probe system, unzip probeWIN.zip in theroot (C:\ by default) directory. This unpackages the zip fileto C:\Program Files\HP OpenView.
4. Go to C:\Program Files\HP OpenView\pdAE\bin
5. Double-click pdpinstall.vbs. This installs the probesoftware in C:\Program Files\HP OpenView\pdAE.
You are prompted for the name of the Problem Diagnosisserver with which the probe will communicate. Enter thefully-qualified DNS name of the assigned server. Forexample, to assign the probe to the Problem Diagnosis server,Minotaur, enter Minotaur.cnd.hp.com when prompted.
Table 4-2 Instructions for Installing Remote Probes (Continued)
Platform of ProbeSystem
Instructions
Chapter 4 63
Problem DiagnosisConfiguring Problem Diagnosis
Configuring Problem DiagnosisA configuration XML file, pdconfig.xml, is created on the ProblemDiagnosis server when Problem Diagnosis is installed. On the systemwhere Problem Diagnosis is installed, the configuration file can be foundat:
UNIX: $OV_MAIN_PATH/pdAE/config/pdconfig.xmlWindows: %OV_MAIN_PATH%\pdAE\config\pdconfig.xml
You can use the configuration XML file to tweak your Problem Diagnosisconfiguration. In particular, use the configuration XML file to:
• Add probes to the list of probes that the Problem Diagnosis serverknows of. See “Linking the Server to a Probe” on page 65.
• Notify servers of a probe’s existence. See “Linking the Probe to aServer” on page 67.
• Tune brownout parameters. See “Configuring Brownouts” onpage 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, butit requires accuracy; mistakes in the configuration XML file can causethe Problem Diagnosis server or probe to not work correctly.
If non-ASCII characters are added to XML files, you must preserve theUTF-8 codeset for these characters.
NOTE The Windows Notepad editor allows files to be saved in the UTF-8 codeset. On many UNIX platforms, the iconv command can be used totranslate from Shift JIS (or any other code set) into UTF-8 to makeediting in a non-UTF-8 codeset simpler.
HP strongly recommends that you make a backup copy of the XML filebefore editing, so that you can easily recover if necessary.
Chapter 464
Problem DiagnosisConfiguring Problem Diagnosis
Linking Servers and Probes
As you install a Problem Diagnosis probe, you assign it to a ProblemDiagnosis server. The two transparently establish the configurationnecessary to communicate, and the probe automatically shows up in theprobe 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 aprobe that was not initially assigned to that server.
• You can add the probe to the list of probes the server knows of. Thismethod is most useful when you want a server to know about severalprobes that it could draw data from; that is, when you have oneserver 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, andlet the server reconfigure itself. This method is most useful when youwant 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. Thisapproach 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 wasassigned to a different server when it was installed:
1. Manually edit the Problem Diagnosis configuration XML file on theProblem Diagnosis server to define which probe(s) the server can use.This file is located at the following location:
UNIX: $OV_MAIN_PATH/pdAE/config/pdconfig.xmlWindows: %OV_MAIN_PATH%\pdAE\config\pdconfig.xml
If you cannot find the configuration XML file on your system, it iscreated when a probe is installed and assigned to the server. Untilthat 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 DiagnosisConfiguring 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", whichidentifies Icarus as hosting a probe that the server can use. You canuse more probes by adding additional Probe Definitions. ProbeDefinitions 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 XMLfile on the server:
<PROBE>
<HOST_NAME> Daedalus.naucrates.com </HOST_NAME>
<IP_ADDRESS> 15.2.116.72</IP_ADDRESS>
</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>
<IP_ADDRESS> 15.2.116.83</IP_ADDRESS>
</PROBE>
<PROBE>
<HOST_NAME> Daedalus.naucrates.com </HOST_NAME>
<IP_ADDERSS> 15.2.116.72</IP_ADDRESS>
</PROBE>
</PROBELIST>
</PD_CONFIG>
Chapter 466
Problem DiagnosisConfiguring Problem Diagnosis
2. After saving the pdconfig.xml file, stop and restart the server toactivate the changes (see “Starting and Stopping the Server” onpage 73). Allow several minutes for the probe and server tosynchronize.
When you access the server, you can now choose to use either Icarusor Daedalus as the probe.
Linking the Probe to a Server
There are two steps to make a probe (which was assigned to one serverwhen 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 probeconfiguration file is located as follows:
UNIX: $OV_MAIN_PATH/pdAE/config/npprobe.confWindows: %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. Whenthe probe initializes, it notifies the server specified here of itsexistence. If necessary, the server adds the probe to its list of knownprobes.
You can have the probe notify additional servers of its presence.Change the bold lines in the probe configuration file to identifyanother server. In the example file above, we can notify anotherProblem Diagnosis server that the probe exists by changing the boldlines in the probe configuration file to give the hostname and IPaddress of the new server, as follows:
SERVER=Aeolus.naucrates.comSERVER_IP=12.12.112.121
Chapter 4 67
Problem DiagnosisConfiguring Problem Diagnosis
IMPORTANT If you modify the existing lines, do not add any additional lines! Theresulting 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 definedby that probe (8068 in this example). If you change the port used by aserver, you have to reconfigure each probe that the server uses (viathe SERVER_PORT definition in npprobe.conf) to use the new port.See the “Configuring the Server Port” on page 71 for instructions onchanging the server port.
NOTE It is not a good idea to have more than one Problem Diagnosis serverconfigured. Since there is no way for one Problem Diagnosis server totalk to another Problem Diagnosis server, it could be difficult toobtain the path information you request.
2. After saving the changes, stop and restart the probe (see “Startingand Stopping a Probe” on page 73). This causes the probe tosynchronize with its server. Because Aeolus has no previousknowledge 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 (likeAeolus), it remains on that list even if you repeat this process to addit 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 theprobe to show path data.
Chapter 468
Problem DiagnosisConfiguring 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 timeexceeds a calculated limit (or threshold), then Problem Diagnosis pingsthe destination once every minute for fifteen minutes, by default. Eachpacket round trip time is noted and compared to its threshold. Bydefault, 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 beoccurring by looking at the nodes (or hops) along a path from the probe tothe destination. When a hop time exceeds its calculated limit, thenProblem Diagnosis assumes that a spike is occurring between that hopand the previous hop.
A brownout event is sent to the alarm browser containing the probe, thedestination, and the two hops where the spike appears to be occurring.
To change the way brownout events are generated, you can modify theProblem Diagnosis configuration file, pdconfig.xml, located at:
UNIX: $OV_MAIN_PATH/pdAE/config/pdconfig.xmlWindows: %OV_MAIN_PATH%\pdAE\config\pdconfig.xml
The Problem Diagnosis configuration file enables you to tune thebrownout 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_INTERVAL
Time in milliseconds that ProblemDiagnosis waits before generatinganother brownout event for a probe anddestination combination.
86400000
Chapter 4 69
Problem DiagnosisConfiguring Problem Diagnosis
Configuring Server and Probe Ports
Ports 8068 and 8067 are used by the Problem Diagnosis server tocommunicate internally (8068), and with probes (8067). If either of theseports has been taken by other software, the port(s) used by the servermust be changed. In the case of port 8068, probes must be reconfigured toreflect changes to the server.
BUCKET_SIZE The number of measurements ProblemDiagnosis stores for a particular hopfrom a particular path to thedestination. After the value is reached,the oldest measurement is replaced bythe newest measurement.
NOTE: This parameter is notrecommended to be changed, especiallyafter data has been collected.
24
BROWNOUT_NUM_SAMPLES
Number of times that ProblemDiagnosis will attempt to ping thedestination device. The frequency thatProblem Diagnosis attempts to ping thedestination device is once per minute.
15
BROWNOUT_NUM_DEVIATIONS
A number used to calculate thethreshold for brownout events. Theformula for determining the threshold isthe BROWNOUT_NUM_ DEVIATIONS timesthe square root of the mean, plus themean.
3
BROWNOUT_BAD_SAMPLES
The number of times that the ping roundtrip time must exceed a threshold beforea brownout event is generated.
8
Table 4-3 Brownout Parameters in Problem Diagnosis Configuration File
Tunable Parameter Description Default Value
Chapter 470
Problem DiagnosisConfiguring Problem Diagnosis
Configuring the Server Port
NOTE Any probe accessed by a server that does not use port 8068 must bereconfigured to accommodate this, and its data will not be available toany server that uses another (such as the default) port.
To change the Problem Diagnosis server port number from 8068 toanother port use the following procedure:
1. Stop the Problem Diagnosis server and stop all probes assigned tothat 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 portnumber that is not used by any other networking software.
3. For all relevant Problem Diagnosis probes, edit<Install_directory>/config/npprobe.conf and replace 8068with 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 toanother port use the following procedure:
1. Stop the Problem Diagnosis server. See “Starting and Stopping theServer” on page 73.
2. Edit the configuration XML file, pdconfig.xml. For each <PROBE>entry, edit the entry <HTTP_PORT>8067<HTTP_PORT>. Replace 8067with a port number that is not used by any other networkingsoftware.
3. On each probe system, edit:UNIX: /etc/servicesWindows: %windir%\system32\drivers\etc\SERVICES
Replace the value of the netpath_http entry with the new portnumber.
4. Restart the server.
Chapter 4 71
Problem DiagnosisConfiguring Problem Diagnosis
Configuring Probes
Problem Diagnosis includes a web-based probe configuration utility. Toconfigure a probe, first start the probe configuration utility as follows:
1. Start the probe to be configured, and also a Problem Diagnosis serverthat uses this probe. These components must both be running beforeyou can proceed. See “Starting and Stopping the Server” on page 73and “Starting and Stopping a Probe” on page 73.
2. Launch Home Base. You can access Home Base from your browserusing the following URL: http://hostname:7510. See “Starting aProblem Diagnosis View” on page 59 for details.
3. From Home Base, select Problem Diagnosis View from the Viewdrop down list and click [Launch View]. The Problem Diagnosismain dialog opens.
4. Click [Configure] to open the Problem Diagnosis Configurationwindow.
From the Problem Diagnosis Configuration window, set probe targetsand collection parameters by doing the following:
1. In the "Select Probe" list, choose the location of the probe you want toconfigure. 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 thefully-qualified name of a destination node. Problem Diagnosis willtrace the paths to this node. Edit other fields in the entry asnecessary; see the Problem Diagnosis Probe Configuration topic inthe Online Help for more details.
3. After adding all desired targets, click [Apply] or [OK]. Both buttonsrecord your changes; [OK] closes the window, [Apply] keeps it open.
See the Problem Diagnosis Probe Configuration topic in the Online Helpfor more details on configuring probes.
Chapter 472
Problem DiagnosisOther Administrative Tasks
Other Administrative TasksThis section describes other administrative tasks that you may need toperform periodically, such as stating and stopping Problem Diagnosisservers and probes.
Starting and Stopping the Server
To start and stop the Problem Diagnosis server, execute the followingfrom a command window prompt:
• To start the Problem Diagnosis server, enter:
UNIX: $OV_BIN\ovstart pdWindows: %OV_BIN%\ovstart pd
• To stop the Problem Diagnosis server, enter:
UNIX: $OV_BIN\ovstop pdWindows: %OV_BIN%\ovstop pd
NOTE This automatically starts and stops the probe on the Problem Diagnosisserver. 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 UNIXoperating systems or [End Process] from the Task Manager onWindows operating systems); doing so my cause irrevocable corruption ofthe Problem Diagnosis data.
Starting and Stopping a Probe
Problem Diagnosis probes start immediately after installation, and areconfigured to run automatically at system startup.
The commands for starting and stopping a Problem Diagnosis probediffer according to the platform on which the probe runs.
Chapter 4 73
Problem DiagnosisOther Administrative Tasks
Note that on Windows operating systems, probes are installed as aWindows 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 iconand select the Manage menu item.
2. In the navigator pane, double-click Servicesand Applications.
3. Double-click Services.
4. In the details pane, select the NetPathservice, and click Stop in the applet toolbar.
To start a probe service, execute:
1. Right-click on the My Computer desktop iconand select the Manage menu item.
2. In the navigator pane, double-click Servicesand Applications.
3. Double-click Services.
4. In the details pane, select the NetPathservice, and click Start in the applet toolbar.
Chapter 474
Problem DiagnosisLimitations and Oddities
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 astack trace (visible in the Java console and/or the server error log)when the browser is exited. The exception is non-fatal, and isignored. The operation of the server is not affected.
• Sometimes a DNS name resolves to multiple hosts, as in the case of aweb farm. To improve performance, web farms and similar scenariosdistribute incoming requests to one of an array of hosts, alwayschoosing the least-busy host. For example, the DNS name ofwww.yahoo.com does not refer to just one host. At this writing,www.yahoo.com resolves to at least eight different IP addresses. Thefinal 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 adestination for each for each web server using each web server’s IPaddress, rather than a defining a single destination using the DNSaddress.
• X-Windowing: Severe display problems (including a complete failureto display the applet) have been observed when using X-windowingprograms to redirect the Java applet display from UNIX® systems toWindows systems.
Chapter 4 75
Problem DiagnosisLimitations and Oddities
• Windows systems only: If HP OpenView VPIS is also installed on thesame system as NNM, you may have problems with the ProblemDiagnosis/NNM integration. A symptom of this conflict is an errormessage similar to this (depending on your JRE):
The procedure entry point ??1List@@UAE@XZ be located in thedynamic link library ovutil.dll
To solve this problem follow these steps:
Install Notes
• The installer cannot use the JRE from Symantec. You must have adifferent JRE in the PATH ahead of the Symantec JRE.
Problem Diagnosis Probe Notes
• When you first install a probe, the associated server should berunning. If it is not, and if it is not started within an hour of theprobe's installation, then it may take up to an hour after the server isstarted for it to establish communications with the probe. You caneliminate this lag by stopping and restarting the probe after startingthe server.
• A default gateway must be permanently configured for any systemthat hosts a probe. If the default gateway is not set, you will seerouting loop error messages when no such loop necessarily exists.
• Path requests where the probe and target endpoints are the samedevice (for example, from rantrave.diatribe.com torantrave.diatribe.com) have unpredictable results.
• Windows only: On some systems, running the probe as a service cancause the screen saver to stop working. This can be a security hazardif the computer will not lock when unattended. If this happens, youmay want to run the probe in standalone mode rather than a service.
Windows Right-click on the My Computer desktop icon, and choosethe Properties menu item. Click on the Advanced tab.Click the Environment Variables button. Find the SystemVariable named Path, and edit its Value so that the NNMbin directory (for example, C:\Program Files\HPOpenView\nnm\bin) comes before the VPIS bin directory(for example, C:\rpmtools\bin). Click Apply, then Close.
Chapter 476
Problem DiagnosisLimitations and Oddities
To remove the probe from the Windows service, use the followingcommands 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 commandsfrom 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 environmentvariable can cause problems starting or running any Java-basedinterface in Problem Diagnosis. Typical symptoms of this are:
— The Problem Diagnosis application window fails to launch, andthe 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 Javainterfaces), you should run Problem Diagnosis under a shell with anempty CLASSPATH, as follows:
UNIX • Open a new terminal window.
• Type: export CLASSPATH=""
• Type: netscape &
• Start Problem Diagnosis from theresulting browser as usual. See“Starting a Problem Diagnosis View” onpage 59.
Chapter 4 77
Problem DiagnosisLimitations and Oddities
See also MOZILLA_HOME Setting for a similar issue.
MOZILLA_HOME Setting
• On UNIX systems there are conditions under which the ProblemDiagnosis applets and/or Online Help will not launch correctly inNetscape. If you have trouble of this kind, follow these steps:
— Exit from Netscape.
— Enter: exportMOZILLA_HOME=<Netscape_Installation_Directory>
— Restart Netscape.
— Restart Problem Diagnosis.
See also CLASSPATH Conflict for a similar issue.
Windows • Open a command window(Start:Programs->Command Prompt).
• Type the following command: setCLASSPATH=""
• Start Problem Diagnosis by launchingyour browser from this commandwindow! See “Starting a ProblemDiagnosis View” on page 59.
Under default installations, thecommands to launch Netscape andInternet Explorer are:
— Netscape: "C:\ProgramFiles\Netscape\Communicator\Program\netscape.exe"
— Internet Explorer: "C:\ProgramFiles\Plus!\MicrosoftInternet\iexplore.exe"
Chapter 478
Problem DiagnosisLimitations and Oddities
Java Oddities
As you may already be aware, Java is still maturing as a technology.During this process of maturation, there remain some minor instabilitiesor, more generously put, “quirks” that you may want to be aware of.Below are some examples. With the exception of the CLASSPATH conflictissue, the workarounds are very simple.
• The following can occur on Windows operating systems whoseDisplay 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 isobscured. It is actually present, but you have to drag the bottomborder of the window down to see it. This only seems to occur if youhave turned on the "Show window contents while dragging" displayoption in your Windows configuration. If this Java quirk is tooannoying, turn off this Windows option.
• The [Go] and [Stop] buttons in the Main Dialog window mayrandomly change colors. This seems to occur most commonly whenanother window overlays the left side of the Main Dialog window andbisects the [Go] button vertically. This problem has only been seenon Windows operating systems, and the culprit is actually the videodisplay driver. If you switch to another Display:Settings:ColorPalette 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 theresults of your request are available. Depending on the Java plug-inand the platform you are using, you may or may not see a "Busy"cursor (something like an hourglass or watch) during this period toindicate that your request is being serviced. If the "Busy" cursor doesnot 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 andthe "Applet Window" warning message. If this happens, just drag thecorner to enlarge the window; the content will be displayed correctly.
Chapter 4 79
Problem DiagnosisLimitations and Oddities
• As noted under Known Limitations—and repeated here because it isa Java quirk—in some situations, your system's Java CLASSPATHenvironment variable can cause problems starting or running anyJava-based interface in Problem Diagnosis. Typical symptoms of thisare:
— The Problem Diagnosis application window fails to launch, andthe 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 Javainterfaces), you should run Problem Diagnosis under a shell with anempty CLASSPATH, as follows:
UNIX • Open a new terminal window.
• Type: export CLASSPATH=""
• Type: netscape &
• Start Problem Diagnosis from theresulting browser as usual. See“Starting a Problem Diagnosis View”on page 59.
Chapter 480
Problem DiagnosisLimitations and Oddities
Windows • Open a command window(Start->Programs->CommandPrompt).
• Type the following command: setCLASSPATH=""
• Start Problem Diagnosis by launchingyour browser from this commandwindow!
Under default installations, thecommands to launch Netscape andInternet Explorer are (quotesrequired):
— Netscape: "C:\ProgramFiles\Netscape\Communicator\Program\netscape.exe"
— Internet Explorer: "C:\ProgramFiles\Plus!\MicrosoftInternet\iexplore.exe"
Chapter 4 81
Problem DiagnosisTroubleshooting Problem Diagnosis
Troubleshooting Problem DiagnosisThis section provides some tips and hints on troubleshooting ProblemDiagnosis.
Cleaning Up a Corrupt Database
The Problem Diagnosis database contains all of the path data collectedfrom the Problem Diagnosis server and all of the remote probes. TheProblem Diagnosis database directory resides on the NNM managementstation 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 berecovered, clean out the contents of the Problem Diagnosis databasedirectory:
1. Stop Problem Diagnosis on the NNM management station byexecuting 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 databasedirectory effectively deletes all of your stored data. This includes all ofthe data collected by the Problem Diagnosis probes.
Chapter 482
Problem DiagnosisTroubleshooting Problem Diagnosis
Checking Status of Problem Diagnosis Server
Typically, you would check the status of an NNM component byexecuting ovstatus. However, sometimes the output from executingovstatus pd indicates that the Problem Diagnosis server is up andrunning when it is not.
The best way to check the status of the Problem Diagnosis server is tocheck the connection to the Problem Diagnosis database. If a connectionto the database can be established, then the Problem Diagnosis server isup and running.
To connect to the database and verify that the Problem Diagnosis serveris 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 hostingthe 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 DiagnosisTroubleshooting Problem Diagnosis
Chapter 484
5 Using the Active ProblemAnalyzer
Chapter 5 85
Using the Active Problem AnalyzerUnderstanding the Basics of the Active Problem Analyzer
Understanding the Basics of the ActiveProblem AnalyzerThe Active Problem Analyzer (APA) monitors device status, analyzesproblems on your network, and displays root cause information forExtended Topology.
The NNM GUI (ovw) uses the netmon process to monitor device status,among other things. Similarly, NNM Advanced Edition’s ExtendedTopology functionality (Extended Topology) uses Active ProblemAnalyzer (APA) to continuously monitor devices that you designate asbelonging to an Overlapping Address Domain (OAD) and report statusinformation. See Chapter 3, “Configuring Overlapping Address DomainDiscovery,” on page 41 for more information.
NOTE There are several documents that discuss NNM Advanced Edition’sfeatures. These documents refer to APA as either Active ProblemAnalyzer or Advanced Problem Analyzer. Both phrases are validreferences to APA.
Extended Topology uses APA to continuously query Hot Standby RoutingProtocol (HSRP) routers and report HSRP group status information. Youmust have a valid license for the Advanced Routing Smart Plug-in (SPI)for NNM to use the HSRP functionality. See Chapter 8, “The AdvancedRouting Smart Plug-in,” on page 237 for more information. Thisdocument assumes you have a valid license for the Advanced RoutingSPI.
APA analyzes the connectivity details from the extended topology toprovide you with accurate HSRP and OAD view status information. Itprovides you with this information in the following ways:
• It analyzes information from neighboring interfaces in order toprovide better diagnostic information.
• It generates alarms indicating the root cause of an HSRP or OADproblem. You will spend less time searching for the root cause of afailure.
• It maintains node, interface, and address status attributes.
Chapter 586
Using the Active Problem AnalyzerUnderstanding the Basics of the Active Problem Analyzer
• It modifies Dynamic View node status colors using node status andother node attributes.
See “Understanding HSRP View Status Information” on page 260 formore information about HSRP status information. See “UnderstandingOAD View Status Information” on page 53 for more information aboutOAD status information.
By default, APA monitors OAD status, and HSRP status if you have avalid license for the Advanced Routing Smart Plug-in. If you want, APAcan largely replace the netmon process for monitoring your wholenetwork.
If you choose to have APA replace the netmon process for monitoringyour whole network, its default configuration allows it to poll devices asshown in Table 5-1. There are a number of factors to consider before youtake that step. This chapter will help you understand APA, and to decidewhat you want it to do.
Table 5-1 Default APA Polling Configuration
Device Type SNMP Polling ICMP Polling
Switch with NoConnectedInterfaces
No Yes
Connected Interfaceon Router
Yes Yes
Connected Interfaceon Switch
Yes No
Connected Interfaceon End Node
No Yes
UnconnectedInterface on Routerwith InterfaceAdministratively Up
Yes Yes
UnconnectedInterface on Routerwith InterfaceAdministrativelyDown
No No
Chapter 5 87
Using the Active Problem AnalyzerUnderstanding the Basics of the Active Problem Analyzer
APA also polls devices for configuration information and determines if itsinterfaces may have renumbered. See “Configuration Polling andInterface Renumbering” on page 105 for more information.
To find out how to enable APA, see See “Enabling and Disabling APA” onpage 109.
NOTE This paper contains references to both Extended Topology and extendedtopology. Extended Topology refers to the overall functionality describedin the Using Extended Topology manual. In contrast, extended topologyrefers to the information discovered by the Extended Topologyfunctionality and the database containing this information.
UnconnectedInterface on Switchwith InterfaceAdministratively Up
No No
UnconnectedInterface on Switchwith InterfaceAdministrativelyDown
No No
Board Yes N/A
Table 5-1 Default APA Polling Configuration (Continued)
Device Type SNMP Polling ICMP Polling
Chapter 588
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
Understanding How APA and the netmonProcess CooperateIf you prefer, you can continue to use the netmon process as your networkmonitor. Except for OAD and HSRP environments, which APA alone canmonitor, ovw has always used netmon for this purpose, and this is thedefault setting.
However, you can make APA your primary network monitor. It offersmore accurate diagnostic information and faster throughput for greaterscalability.
NOTE Regardless of whether you have the netmon process or APA doing yourgeneral IPv4 network monitoring, the netmon process is still essential fordevice discovery.
To summarize, in addition to having APA monitor IPv4 addresses thatyou designate as belonging to an OAD, you can make APA poll all of theIPv4 interfaces listed in the hosts.nnm file (general IPv4 interfaces).Once you complete your first Extended Topology discovery, you can viewthese general IPv4 entries in the hosts.nnm file by looking in thefollowing location:
• Windows:%OV_DB%\nnmet\hosts.nnm
• UNIX: $OV_DB/nnmet/hosts.nnm
See Chapter 2, “Extended Topology Discovery,” on page 19 for moreinformation about Extended Topology discovery.
Before you switch over to APA monitoring, however, you shouldunderstand the differences between the netmon process and APA. WhileAPA offers several significant advantages over the netmon process, someusers will find one or two specific characteristics of the netmon processthat make it indispensable to them.
You may have NNM installed as a management station in an NNMdistributed environment. Do not enable APA on NNM when it functionsas a management station with collection stations reporting information to
Chapter 5 89
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
it. You can enable APA on NNM if it only functions as a collection stationor as a standalone management station, having no collection stationsreporting information to it.
If you enable APA to poll your general IPv4 interfaces, it provides youwith more accurate diagnostic information. Here is a brief summary ofthe advantages APA offers when diagnosing network failures:
• It analyzes information from neighboring interfaces and verifies thatthe failure is real before generating the alarm.
• It identifies link failures based upon Extended Topologyconnectivity.
• It suppresses transient failures due to spanning tree reconvergence.
• It polls devices using both SNMP and ICMP as it deems appropriatefor the situation.
• It improves polling performance by ignoring unconnected interfacesand utilizing multi-threaded processes.
• It updates status information for objects in both ovw and DynamicViews.
If you have APA take over the general IPv4 interface polling, the netmonprocess stops monitoring these interfaces. As APA makes status changesto the extended topology, it sends updates about the statuses ofovw-based interfaces to the ovtopmd process.
The ovtopmd process generates status events as it normally does. Itpasses this status information to the ipmap process, and ultimately, theovw user interface. Dynamic Views get their information from theextended topology if it is available for a node, returning to the ovtopmdprocess for status if necessary.
Chapter 590
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
Table 5-2 compares APA with the netmon process. This should helpclarify 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 fromovtopmd.
APA takes its polling listexclusively from the extendedtopology. You need to make surethat your important nodes are notblocked by thebridge.noDiscover file.
APA does not generate statusalarms for devices in the generalIP environment. NNM alarmsappear as they normally do.
NNM generates APA alarms only.It does not generate NNM statusalarms. See the trapd.confreference page (or the UNIXmanpage) for more information.
NNM events participate inevent correlation and appear inthe Alarm Browser.
APA events participate in eventcorrelation and appear in theAlarm Browser after verification.
Root cause analysis is based onnetmon process informationavailable to ECS. Alarms aresent for every device affected bya failure.
Events that communicatetopology changes to other NNMprocesses may be logged and notused by ECS.
Root cause analysis is based onAPA’s more detailed informationavailable to ECS. A single alarm issent only for the actual root cause,not one for each affected device.
NNM considers an address to bean interface object.
There are separate board,interface, and address objects.Extended Topology and APA allowfor multiple boards per node,multiple interfaces per board, andmultiple addresses per interfacewith each interface having its ownstatus.This clarity of status allowsbetter propagation to node status.
Chapter 5 91
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
The netmon process derivesdevice interface status usingICMP (or SNMP if the device isa switch).
You can add addressinformation to thenetmon.snmpStatus file to haveNNM use SNMP status pollingfor specific interfaces. Doing thisturns off ICMP polling for thetargeted interfaces. See thenetmon reference page (or theUNIX manpage) for moreinformation.
APA uses both ICMP and SNMP todetermine interface status,depending on the APAconfiguration.
ovw shows propagated interfacestatus. Status propagation is thesole basis for node, segment,and network status.
Some objects have their own basisfor status. For example, HSRPanalyzes the various status valuesto determine HSRP group status.
Internally, the ovtopmd processgenerates status change eventsfor each device affected by afailure.
The ovet_poll process generatesstatus alarms. It does not sendsecondary failure alarms. APAchanges the status in the extendedtopology and only the root causeevent is sent through the eventsystem.
The ipmap process listens to thevarious status change alarmsand updates node, segment, andnetwork status.
Dynamic Views listen for anddisplay topology changes.Theovet_poll process sendsExtended Topology node status toovw nodes, segments, andnetworks.
Table 5-2 Comparing APA and the netmon Process
NNM Prior to Enabling APA NNM with APA Enabled
Chapter 592
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
How APA and the netmon Process Share Information
The following information provides some additional details on how APAand the netmon process cooperate with each other:
• APA can behave in two different ways:
— It can monitor HSRP and OAD only, which is the defaultbehavior.
— You can enable APA to monitor everything that exists in theextended topology. See “Enabling and Disabling APA” onpage 109 for more information.
• If you enable APA, it forwards status information to both theovtopmd process and Extended Topology. However, APA onlyforwards critical device status information to ovtopmd. As a result,NNM only displays node, interface, or address status pointing to thepossible root cause of the failure. NNM will not display all of thesecondary status failures in ovw. NNM does not change the ovwstatus for secondary nodes.
• Dynamic Views show extended topology status when available; theyshow status that comes from the ovtopmd process when APA is notmonitoring a device or interface. Devices not being monitored by APAare 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 adevice, it will display information as follows:
— If APA is monitoring a node, the pages display extended topologyand APA status information.
Dynamic Views get status fromthe ovtopmd process for nodesand interfaces.
Dynamic Views get status fromthe extended topology. If youenable APA for IP, the ovtopmdprocess gets its IP status fromAPA.
Table 5-2 Comparing APA and the netmon Process
NNM Prior to Enabling APA NNM with APA Enabled
Chapter 5 93
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
— If the netmon process is monitoring a node, the page displaysstatus 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 fornodes that are not immediately adjacent to the detected fault. Itattempts to generate one alarm showing the root cause of a failure.
If APA determines that a node is down, it generates anOV_APA_NODE_DOWN alarm for the node and sets the status tocritical. This alarm name implies a primary failure.
Failures detected on the other side of a known fault are a result of thatfault, and APA calls them secondary failures. You can see thesesecondary failures by drilling down from the corresponding primaryfailure. This eliminates alarms from the Alarm Browser for devices thatare not known to have failed.
APA and Failure Analysis Details
During failure analysis, APA attempts to distinguish among thefollowing three areas of the network:
• Normal Area: The area of the network near the management stationwhere all the devices are operational and can be accessed via ICMPor SNMP. This area could be large (multiple hops).
• Fault Area: This area includes devices that contain a fault or aredirectly connected to a device downstream from the managementstation that contains a fault. This area will always contain at leastone device that is up and responding to SNMP.
• Far-From-Fault Area: This area corresponds to devices that aredownstream from the fault. That is, if you traverse a path from themanagement station to these devices, you will sequentially passthrough the Normal Area and the Fault Area, and finally arrive atthe devices in the Far-From-Fault Area.
APA handles each of the these areas differently:
Chapter 594
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
• Normal Area: Devices located in this area are up and responding.Device statuses should be normal (or responding for addresses) inthe extended topology. You may see an OV_APA_xxx_UP alarm (wherexxx is NODE, IF, CONNECTION, ADDR,BOARD, or AGGPORT) if a device wasin the Fault Area and the fault has been fixed.
• Fault Area: APA analyzes this area, determines the most likely rootcause object (node, interface, connection, address, board, oraggregated port), and generates a single alarm for this object.
NOTE Information presented in this section considers the term down to besynonymous with the term critical. These terms can be used inseveral ways:
— Either term may imply a status of critical in the extendedtopology. APA may emit an OV_APA_xxx_DOWN alarm for criticaldevices.
— Either term can refer to a device being unresponsive due to thefailure of another device between the management station andthe device.
The information provided in this section carefully sets the context sothat you can interpret the proper meaning of these terms.
For example, if APA determines that a node is down, it will emit anOV_APA_NODE_DOWN alarm for the node. In this example, APAconsiders objects contained by the node (interfaces, addresses, andboards) to be secondary failures and displays them with an unknownstatus in the extended topology. APA will emit anOV_APA_IF_UNREACHABLE, OV_APA_ADDR_UNREACHABLE,OV_APA_BOARD_UNREACHABLE, or OV_APA_CONNECTION_UNREACHABLEalarm as appropriate.
An interface in the extended topology may contain one or moreaddresses. If an interface status changes to down or unreachable, allcontained addresses (that are polled) will change status tounreachable and an OV_APA_ADDR_UNREACHABLE alarm to beemitted.
NOTE An alarm name that contains the term DOWN, as inOV_APA_NODE_DOWN, implies a primary failure.
Chapter 5 95
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
An alarm name containing the term UNREACHABLE, as inOV_APA_IF_UNREACHABLE, implies a secondary failure.
Objects that are experiencing a secondary failure are failing becauseof a primary failure object. Alarms for secondary failures are notdirectly visible in the alarm browser. They can only be seen bydrilling down from the corresponding primary failure.
• Far-From-Fault AreaThis area consists of devices that are not faultybut are effected by the fault. APA does not emit an alarm for thesedevices, but sets the status to unknown (or unreachable foraddresses) in the Dynamic Views. APA inhibits alarm generation inthis area, eliminating clutter from the alarm browser by excludingalarms for devices that are not in the Fault Area. This greatlyimproves the performance of the alarm system.
NOTE Although APA excludes alarms from the Alarm Browser for alldevices that are located in the Far-From-Fault area, you can changethis behavior. You can configure APA to emit the alarms forimportant nodes that you designate. See “Configuring APA toDisplay Alarms from Important Nodes” on page 118 for moreinformation.
To illustrate the performance improvement, suppose a fault occurs,resulting in 1,000 inaccessible nodes. Suppose each of these nodescontained four interfaces and five addresses. Although APA mightonly 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) foreach of the inaccessible nodes (in this case, 1000 nodes). In thisexample, without eliminating alarm generation, APA would have tochange the status of 10,000 objects in the Far-From-Fault Area. Bynot generating the corresponding 10,000 alarms associated with theFar-From-Fault Area, we avoid inefficiently using pmd process, ECScorrelation 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) cannotaccess nodes G, H, and E. Node F’s failure will cause all of Node F’sinterfaces to fail. This also causes the connected interfaces on nodes
Chapter 596
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
C and D to fail. The management station, node N, and node B remainup since they are accessible by the management station and are inthe Normal Area, away from the fault.
Figure 5-1 APA Analysis Areas
When APA analyzes the Fault Area, it identifies node F as the rootcause. APA considers the interfaces that connect node C to node F tobe secondary failures. Similarly, the interfaces that connect node D tonode F are considered secondary failures. In this example, APA emitsonly one alarm, OV_APA_NODE_DOWN F, that is visible in the top levelof the alarm browser. From the OV_APA_NODE_DOWN F alarm, you candrill 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 alarmsidentify two interface objects as the target of the alarm. TheOV_APA_NODE_DOWN and OV_APA_IF_DOWN alarms identify a singlehost and interface target object respectively.
In summary, APA finds the nodes and interfaces that are in the FaultArea, modifies the status appropriately, and sends out theappropriate alarms. In addition, the APA finds the nodes in theFar-From-Fault Area and adjusts the status, but does not generateany alarms.
MS N B
C
D
F G H E
Normal Area Fault Area Far-From-Fault Area
Normal Minor
Critical Unknown
(APA emits no alarms)
Chapter 5 97
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
APA and Dynamic View Status APA reports object status in theDynamic Views using the colors shown inTable 5-3.
Handling SNMP Traps from Network Devices You can configurethe SNMP agents on many network devices to send SNMP traps to anNNM management station’s hostname or IP address. In many cases,when APA receives traps, it initiates an immediate poll of the devicegenerating the SNMP trap. When APA receives any of the followingtraps, it will take the associated action:
• SNMP_Link_Down or SNMP_Link_Up: APA analyzes the source’sinterfaces.
• SNMP_Cold_Start or SNMP_Warm_Start: APA analyzes the sourceand its configuration.
• Cisco_Link_Down or Cisco_Link_Up: APA analyzes the source’sinterfaces and its configuration.
Table 5-3 APA Status Conditions
Dynamic ViewStatus Color Dynamic View Status Description
Not Monitored (tan) APA is not actively polling the object (node,interface, connection, address, board, oraggregated port).
Unknown (blue) APA cannot communicate with the object, orconsiders the object to be a secondaryfailure. APA cannot determine the status ofunreachable objects.
Disabled (brown) The object’s interface is administrativelydown.
Normal (green) The object is functioning normally.
Minor (yellow) The object is functioning, but othercontained objects, such as interface,connection, address, board, or aggregatedport objects are not functioning.
Critical (red) The object is not functioning normally.
Chapter 598
Using the Active Problem AnalyzerUnderstanding How APA and the netmon Process Cooperate
• Cisco_Cold_Start or Cisco_Warm_Start: APA analyzes thesource’s interfaces.
• Cisco_HsrpStateChange: APA analyzes the HSRP group.
• Cisco_ModuleUp or CiscoModuleDown: APA analyzes the source andits configuration.
• ciscoLS1010ChassisChangeNotification: APA analyzes thesource and its configuration.
Chapter 5 99
Using the Active Problem AnalyzerUnderstanding APA and View Status
Understanding APA and View StatusThe information contained in this section discusses how APA affects thedisplayed 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 formore information.
APA monitors tracked interfaces as configured on the routers containedin the HSRP group. For example, in Figure 5-2, Router A contains anactive interface 1 in the HSRP group with a priority of 100. Router B is astandby router in the HSRP group and contains interface 2 with apriority 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 HSRPview displays the new priority value and the interface state changes.
Figure 5-2 How APA Monitors Tracked Interfaces
Server
Router A
Router B
Interface 1
Interface 2
HSRP Group
Tracked Interface 3
State: ActivePriority 100
State: StandbyPriority: 55
Priority 50
Chapter 5100
Using the Active Problem AnalyzerUnderstanding APA and View Status
Understanding APA, Layer 3 Polling, and Node Status
APA only updates the status of the device or interface identified as theprimary failure and synchronizes only the primary node or interfacestatus with the ovtopmd process and the ovw user interface. The result isthat APA only updates the ovw user interface with the primary faultstatus. Once the faulty device is functioning properly, APA polls thedevice and the status returns to normal.
APA considers nodes located outside of the Fault Area to be secondaryfailures. APA does not update the ovw user interface with the status ofthese nodes.
NOTE APA does not support IPX networked devices, IPX interfaces, or anydevices not residing in the hosts.nnm file. APA does support OADdevices.
Understanding Board Status and the ovw User Interface
APA polls a node’s board status using SNMP as shown in Table 5-1 onpage 87. Suppose that APA finds and reports a board down, where thereare no interfaces down within the board or within the node itself. In thisexample, NNM AE sets the extended topology node status to minor, andgenerates an OV_APA_BOARD_DOWN alarm. However, the node statusin the ovw user interface remains normal, as the ovw user interface doesnot take board status into consideration when determining node status.
Chapter 5 101
Using the Active Problem AnalyzerUnderstanding APA and Event Reduction
Understanding APA and Event ReductionWhen you enable APA, it disables the status polling feature of thenetmon process and establishes the ovet_poll process as the pollingengine. The ovet_poll process contains alarm types beginning withOV_APA. The following list describes the new alarms that APA maydisplay or log:
• OV_APA_ADDR_DOWN: APA generates this alarm when it detectsthat a network entity’s address status goes from up to down.
• OV_APA_ADDR_Intermittent: APA generates this alarm when itdetects that a network address’s status has gone down and upmultiple times.
• OV_APA_ADDR_UNREACHABLE: APA generates this alarm whenit detects that an address is unreachable due to another failure, suchas the address’s interface being down.
• OV_APA_ADDR_UP: APA generates this alarm when it detects thata network entity’s address status goes from down to up.
• OV_APA_AGGPORTCONN_DOWN: APA generates this alarm whenthe aggregate port connection between two nodes is not respondingto polls and all interfaces may be down on both sides of theconnection.
• OV_APA_AGGPORTCONN_UNREACHABLE: APA generates thisalarm when the aggregate port connection between two nodes is notresponding to polls on both sides of the connection. The problem isprobably due to another entity.
• OV_APA_AGGPORTCONN_UP: APA generates this alarm when theaggregate port connection between two nodes is responding to pollsand no interfaces are down on either side of the connection.
• OV_APA_AGGPORT_DEGRADED: APA generates this alarm whenthe aggregate port connection between two nodes is responding topolls and some of the interfaces are down.
• OV_APA_AGGPORT_DISABLED: APA generates this alarm whenthe aggregate port is not responding to polls in a normal fashion.This could be because all the interfaces’ ifAdminStatus are down ortesting. This aggregate port is the primary failure.
Chapter 5102
Using the Active Problem AnalyzerUnderstanding APA and Event Reduction
• OV_APA_AGGPORT_DOWN: APA generates this alarm when theaggregate port connection between two nodes is not responding topolls and all interfaces may be down.
• OV_APA_AGGPORT_UNREACHABLE: APA generates this alarmwhen the aggregate port connection between two nodes is notresponding to polls. The problem is probably due to another entity.
• OV_APA_AGGPORT_UP: APA generates this alarm when theaggregate port connection between two nodes is responding to pollsand no interfaces are down.
• OV_APA_BOARD_DOWN: APA generates this alarm when it detectsthat a node’s board status goes from up to down.
• OV_APA_BOARD_REMOVED: APA generates this alarm when itdetects that a node’s board has been removed.
• OV_APA_BOARD_UNREACHABLE: APA generates this alarmwhen it detects that a node’s board stops responding to polls due toanother entity in the network.
• OV_APA_BOARD_UP: generates this alarm when it detects that anode’s board status goes from down to up
• OV_APA_CONNECTION_DOWN: APA generates this alarm when itdetects that a connection’s status goes from up to down.
• OV_APA_CONNNECTION_Intermittent: APA generates this alarmwhen it detects that a network connection’s status has gone downand up multiple times.
• OV_APA_CONNECTION_UNREACHABLE: APA generates thisalarm when it detects that a connection is unreachable due toanother failure.
• OV_APA_CONNECTION_UP: APA generates this alarm when itdetects that a connection’s status goes from down to up.
• OV_APA_DEMAND_POLL: HP OpenView processes generate thisalarm when they want APA to poll a specific network entity.
• OV_APA_IF_DISABLED: This specific alarm indicates that theinterface is not responding to polls in a normal fashion. This could bebecause the interface’s ifAdminStatus is down or testing.
• OV_APA_IF_DOWN: APA generates this alarm when it detects thata network entity’s interface status goes from up to down.
Chapter 5 103
Using the Active Problem AnalyzerUnderstanding APA and Event Reduction
• OV_APA_IF_Intermittent: APA generates this alarm when it detectsthat an interface’s status has gone down and up multiple times.
• OV_APA_IF_UNREACHABLE: APA generates this alarm when itdetects that an interface is unreachable due to another failure.
• OV_APA_IF_UP: APA generates this alarm when it detects that anetwork entity’s interface status goes from down to up.
• OV_APA_Message: APA generates this alarm to reflect changes inthe network that are best communicated through text. This alarm ismainly used for internal troubleshooting.
• OV_APA_NODE_DOWN: APA generates this alarm when it detectsthat a node’s status goes from up to down.
• OV_APA_NODE_Intermittent: APA generates this alarm when itdetects that a node’s status has gone down and up multiple times.
• OV_APA_NODE_RENUMBERING: APA generates this alarm whenit detects that the interfaces or boards on a node were renumbered.
• OV_APA_NODE_RENUMBERING_FIXED: APA generates thisalarm when it detects that the interfaces or boards on a node nolonger appear to have been renumbered. This can happen after arediscovery, and will clear the priorOV_APA_NODE_RENUMBERING alarm for this node.
• OV_APA_NODE_UNREACHABLE: APA generates this alarm whenit detects that a node is unreachable due to another failure, such asand upstream node being down.
• OV_APA_NODE_UP: APA generates this alarm when it detects thata node’s status goes from down to up.
• OV_APA_POLL: HP OpenView processes generate this alarm whenthey want APA to poll a specific network entity.
• OV_APA_Statistics: APA generates this alarm to report variousexecution statistics that are useful for monitoring its performance.
NOTE APA does not actually generate the IntermittentStatus alarms, theyare generated by the OV_PollerIntermittent correlators. Thesecorrelators, if enabled, generate the OV_APA_ADDR_Intermittent,OV_APA_IF_Intermittent, OV_APA_NODE_Intermittent, andOV_APA_CONN_Intermittent alarms. This only happens if the
Chapter 5104
Using the Active Problem AnalyzerUnderstanding APA and Event Reduction
OV_PollerIntermittent correlators are enabled, and after APAgenerates multiple down events within the time window specified inthose correlators.
For specific Correlation Composer deployment information, includinghow to efficiently use the HP OpenView Correlation Composer, refer tothe HP OpenView Correlation Composer’s Guide.
For more information about APA alarms, see the trapd.conf referencepage (or the UNIX manpage).
As mentioned earlier, APA generates alarms for primary failures in mostcases. This eliminates alarms from the Alarm Browser for devices thatare not known to have failed. NNM also includes several of the new APAalarms in existing ECS correlations such as ConnectorDown and PairWise correlations.
For more information about alarm reduction with NNM, see theManaging your Network manual.
Configuration Polling and Interface Renumbering
Some device configuration activities may cause SNMP agents torenumber SNMP MIB instance values of some Ethernet switches androuters. 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 androuters. 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 lastconfiguration check. Any deviation from the last ifAlias, ifName,ifDescr, or ifPhysAddress values can be a symptom caused by adevice’s interfaces being renumbered.
Chapter 5 105
Using the Active Problem AnalyzerUnderstanding APA and Event Reduction
If APA determines that interface renumbering activity has occurred, itemits an OV_APA_NODE_RENUMBERING alarm, and displays a message inthe Discovery Status area of Home Base. This message tells you thezone in which the renumbering occurred. You need to initiate a newdiscovery for this zone in order to update the extended topology databasewith the new ifIndex value information.
If you want to see more information, APA logs the details about eachOV_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 moreinformation.
NOTE You can update the status of a device and check to see if interfacerenumbering 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 anOV_APA_NODE_RENUMBERING alarm in the Alarm Browser.
Once Extended Topology completes a new discovery for this zone, APAremoves the OV_APA_NODE_RENUMBERING alarm from the alarm browser.
See the trapd.conf reference page (or the UNIX manpage) for moreinformation.
Disabling or Adjusting the Frequency of Configuration Polling
If you do not want to track interface renumbering for your switches orrouters, or want to adjust the configuration polling interval, use thefollowing procedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the following polling interval text:
Chapter 5106
Using the Active Problem AnalyzerUnderstanding APA and Event Reduction
<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, modifythe bold number to the desired number of seconds.
• If you want to completely disable the configuration polling,change the bold true to false.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
Chapter 5 107
Using the Active Problem AnalyzerUnderstanding APA and Event Reduction
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Chapter 5108
Using the Active Problem AnalyzerEnabling and Disabling APA
Enabling and Disabling APAIf you choose to have APA monitor your general IPv4 interfaces, itdisables the polling feature of the netmon process and enables APA.
NOTE APA takes its polling list exclusively from the extended topology, whichincludes general IPv4 interfaces discovered by the netmon process andplaced in the hosts.nnm file. You need to make sure that your importantnodes are not blocked by the bridge.noDiscover file.
• As Administrator or root, run the following script to enable APApolling 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 APAand 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 youdo this, APA continues to monitor addresses that you designate asbelonging to an OAD, query HSRP routers, and report HSRP groupstatus information
See the ovet_apaConfig.ovpl reference page (or the UNIX manpage)for more information.
Chapter 5 109
Using the Active Problem AnalyzerConfiguring APA
Configuring APAYou may need to adjust APA to optimize it for your particularenvironment. Prior do making any APA adjustments, it is a good idea tounderstand how APA is performing.
Understanding APA Polling Statistics
NNM collects information that shows how APA is performing. FromHome Base, select the Polling/Summary Analysis tab. The resultingview shows information from the Active Problem Analyzer (and not fromNNM’s netmon process). APA statistics are collected on five-minuteintervals. The statistics are as follows:
• Active Analyzer Tasks: This represents the number of polling resultsthat are currently under analysis. This number should trend towardzero when the network is stable. If this number never trends towardzero, you may need to increase the number of threads in the statusanalyzer thread pool. See “Adjusting the Number of Threads in theStatus Analyzer Thread Pool” on page 116.
If the number of Active Analyzer Tasks begins to steadilyincrease, then you are experiencing network problems. Look in theAlarm Browser for an alarm that indicates the root cause of yournetwork problem.
• Waiting Poller Tasks: This represents the maximum number ofpolling tasks that were waiting to be completed during the lastpolling interval. Track the quantity of Waiting Poller Tasks thatis normal for your environment. If this number begins to increase, itindicates that the APA poller is unable to keep up with the pollingload.
To remedy this, review the following list and make adjustments ifnecessary.
— Make sure NNM and Extended Topology are only monitoringyour critical devices.
— Increase the default polling interval. See “Changing the DefaultPolling Interval” on page 113 for more information. Do not adjustthis number too low, as that can create performance problemswhen large quantities of network problems occur.
Chapter 5110
Using the Active Problem AnalyzerConfiguring APA
— Increase the polling intervals of any of the device classes. See“Changing the Polling Interval by Device Class” on page 114 formore information. Do not adjust this number too low, as that cancreate performance problems when large quantities of networkproblems occur.
— Increase the polling engine thread pool size. See “Adjusting theNumber of Threads in the Polling Engine Thread Pool” onpage 117 for more information. Do not adjust this number toolow, as that can create performance problems when largequantities of network problems occur.
• Addresses Polled (ICMP): This represents the number of addressesthat were pinged during the last statistics reporting interval. Trackthe quantity of Addresses Polled (ICMP) that is normal for yourenvironment. This number is an indication of how busy your APApolling engine is. Make sure NNM and Extended Topology are onlymonitoring your critical devices.
• Interfaces Polled (SNMP): This represents the number of interfacesthat were queried for status through SNMP during the last reportinginterval. Track the number of Interfaces Polled (SNMP) that isnormal for your environment.This number is an indicator of howbusy your APA polling engine is. Make sure NNM and ExtendedTopology are only monitoring your critical devices.
• Waiting Analyzer Tasks: This represents the number of pollingresults waiting to be analyzed. When a series of failures occur, thisnumber rises. If this number continues to rise over several pollingcycles, it indicates a serious issue in the network. A temporary surge,which then trends toward zero, is normal when a fault or changeoccurs.
• HSRP Groups Polled: This represents the number of HSRP groupsthat were queried for status during the last reporting interval. Trackthe HSRP Groups Polled number that is normal for yourenvironment. This number is an indication of how busy your APApolling engine is. Make sure NNM and Extended Topology are onlymonitoring your critical HSRP devices.
• Boards Polled: This represents the number of boards that werequeried for status through SNMP during the last reporting interval.Track the number of Boards Polled (SNMP) that is normal for your
Chapter 5 111
Using the Active Problem AnalyzerConfiguring APA
environment.This number is an indicator of how busy your APApolling engine is. Make sure NNM and Extended Topology are onlymonitoring your critical devices.
Adjusting APA Polling Parameters
APA allows you to manually adjust the status polling frequencies. Youcan adjust polling intervals based upon extended topology filters. Usingthis method, you can apply configuration attributes based upon thecapability, or class, of a device.
NOTE You must have a basic understanding of XML concepts, terms, andsyntax before attempting to edit the paConfig.xml file. Without thatknowledge, it is very easy to make serious errors. It is assumed that youhave adequate expertise in XML terminology and syntax, as this bookdoes not define XML terms or explain XML tagging or syntax.
You can make modifications to APA polling frequencies. However thereare only a few parameters you will want to modify. The following filecontains 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 thePolling Engine section of the xml file:
<subSystemConfig>
<name>PollingEngine</name>
<title>Polling Engine</title><subSystemConfig>
• Status Analyzer
You can easily recognize this section, as the following tags begin theStatus Analyzer section of the xml file.
<subSystemConfig>
<name>StatusAnalyzer</name>
Chapter 5112
Using the Active Problem AnalyzerConfiguring APA
<title>Status Analyzer</title>
• Talker
You can easily recognize this section, as the following tags begin theTalker section of the xml file.
<subSystemConfig>
<name>Talker</name>
<title>Talker SubSystem</title>
• StatusBridge
You can easily recognize this section, as the following tags begin theStatus 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 wellas 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 notbelonging to a specific device class. To do this, use the followingprocedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the following polling interval text:
<classSpecificParameters>
<!-- Default parameters for when no class of device is specified. -->
<defaultParameters>
Chapter 5 113
Using the Active Problem AnalyzerConfiguring APA
<parameterList>
<parameter>
<name>interval</name>
<title>Interval to Poll Device</title>
<description>
The interval which the device will be polled in seconds.
</description>
<varValue>
<varType>Integer</varType>
<value>300</value>
</varValue>
</parameter>
Change the bold number to the number of seconds you want APA towait before again polling devices that do not belong to any defineddevice class. Make sure to save your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
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 pollingintervals by device class. The polling interval of a device class takesprecedence over the default polling interval discussed in “Changing theDefault Polling Interval” on page 113.
Suppose you want to modify the router polling frequency. To do this, usethe following procedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
Chapter 5114
Using the Active Problem AnalyzerConfiguring APA
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the isRouter filter text that looks as follows:
<classSpecification>
<filterName>isRouter</filterName>
<parameterList>
<parameter>
<name>interval</name>
<title>Interval to Poll Device</title>
<description>
The interval which the device will be polled in seconds.
</description>
<varValue>
<varType>Integer</varType>
<value>300</value>
</varValue>
</parameter>
Modify the bold number to the number of seconds you want APA towait before repolling devices that pass the isRouter filter. Makesure to save your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
This applies your changes to the APA polling process.
Chapter 5 115
Using the Active Problem AnalyzerConfiguring APA
The filter name is shown in bold print in the above example. Using asimilar procedure, you can modify the polling frequency for devicesthat pass other topology filters. Look for filters with the followingnames:
• isSwitch
• isEndNode
Adjusting the Number of Threads in the Status Analyzer ThreadPool
You can adjust the number of threads in the status analyzer thread pool.This increases the number of threads servicing the status analyzer. Thiscould improve the status analyzer performance, however increasing thisnumber increases the system resources that APA consumes.
To increase the number of threads in the status analyzer thread pool, usethe following procedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
2. As Administrator or root, edit the paConfig.xml file.
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.
Chapter 5116
Using the Active Problem AnalyzerConfiguring APA
</description>
<varValue>
<varType>Integer</varType>
<value>10</value>
</varValue>
</parameter>
Change the bold number to the number of threads you want in theanalysis thread pool. Make sure to save your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Adjusting the Number of Threads in the Polling Engine ThreadPool
You can adjust the number of threads in the polling engine thread pool.This increases the number of threads servicing fault analysis. This couldimprove polling engine performance, however, increasing this numberincreases the system resources that APA consumes.
To increase the number of threads in the polling engine thread pool usethe following procedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the following polling engine thread pool text:
<parameter>
Chapter 5 117
Using the Active Problem AnalyzerConfiguring 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>
<varType>Integer</varType>
<value>16</value>
</varValue>
</parameter>
Change the bold number to the number of threads you want in thepolling engine thread pool. Make sure to save your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Configuring APA to Display Alarms from Important Nodes
APA does not emit failure alarms for devices that are located in theFar-From-Fault area. This means that if a failure occurs, APA will notgenerate any failure alarms for these devices.
APA emits secondary failure alarms for devices that are not located inthe Far-From-Fault area and are not considered primary failures. APAemits these alarms as OV_APA_alarmname_Unreachable alarms andcorrelates them beneath the primary failure alarm.
Chapter 5118
Using the Active Problem AnalyzerConfiguring APA
If your network contains important devices that are critical to yourenvironment, you may want to configure APA to always senduncorrelated alarms associated with these devices to the alarm browser.
To configure APA to emit the alarms for these important nodes, anddisplay them in the Alarm Browser as primary failure alarms, you candesignate a list of important nodes. This important node list enables APAto generate the OV_APA_NODE_UNREACHABLE andOV_APA_CONNECTION_UNREACHABLE alarms for these devices, and displaythem as primary failure alarms in the Alarm Browser.
NOTE Only add the most important devices, those devices that are critical toyour environment, to your important nodes list. Adding smallerquantities 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 yourneeds using the syntax in one of the following examples. In theseexamples, 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
Using the Active Problem AnalyzerConfiguring APA
Using Topology Filters
The paConfig.xml file uses extended topology filters to limit the devicesto which you make polling configuration changes. To get a listing of thefilter names, use the ovet_topodump.ovpl -lfilt command. To verifythe nodes selected by a filter, run the ovet_topodump.ovpl -node-filt filter_name. See the ovet_topodump.ovpl reference page (or theUNIX manpage) for more information.
Implementing a Topology Filter
The Polling Engine subsystem in the paConfig.xml file contains a PollingSettings 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 theydo not pass any of the extended topology filters within the configGrouplist.
If a device belongs to any of the device classes specified beneath the<classSpecification> xml tag, then APA polls the device according tothe 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>
<name>interval</name>
<title>Interval to Poll Device</title>
<description>
The interval which the device will be polled in seconds.
</description>
<varValue>
<varType>Integer</varType>
<value>300</value>
</varValue>
</parameter>
Chapter 5120
Using the Active Problem AnalyzerConfiguring APA
<parameter>
<name>snmpEnable</name>
<title>Enable polling via SNMP</title>
<description>
Enable/Disable polling of a device via SNMP.
</description>
<varValue>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
You can use extended topology filters to add device classes into thepaConfig.xml file to categorize devices in your environment.
TIP You may find some basic knowledge of XML to be helpful when makingchanges to the paConfig.xml file. Changes you make that are notdiscussed here are risky and unsupported.
For example, if you want to create one location in the paConfig.xml fileto adjust the APA polling of your HP ProCurve devices, use the followingprocedure:
1. Run the ovet_topodump.ovpl -lfilt command to see a list of theexisting filters. The output will look something like this:
APANoPollNodesAccessPortAdminDownInterfaceAdminUpOrTestInterfaceAlcatelDevicesAllBoardsAllVirtualAddressAvayaIptDevicesBayDevicesCiscoDevicesCiscoRouterConnectedEndNodeConnectedIF
Chapter 5 121
Using the Active Problem AnalyzerConfiguring APA
ConnectedIFInInfrDevConnectedNodeExceptionInfrDevExceptionNodeExtremeDevicesHasBoardsHSRPCoreGroupIFConnectedToEndNodeIfTypeFilterImportantNodesInfrDevInterfaceInEndNodeInterfaceInInfraDevInterfaceInRouterInterfaceInSwitchInterfaceWithMPLSNameInterfacesWithAnycastAddrsInterfacesWithDupAddrsNoPingAddressesNodeWithDownInterfaceNodeWithMPLSIdNodesWithBoardsNodesWithRhinoMIBNodesWithStackMIBNonSnmpNodeNonSnmpSwitchNortelDevicesNotConnectedIFNotConnectedNodeNotConnectedSnmpRouterNotConnectedSnmpSwitchProcurveDevicesRHINOMIBSTACKMIBSnmpEndNodeSysNameThreeComDevicesTrunkPortUnconnectedAdminDownRouterIFUnconnectedAdminDownSwitchIFUnconnectedAdminUpOrTestRouterIFUnconnectedAdminUpOrTestSwitchIFUnconnectedEndNodeWanIFisATMisCDP
Chapter 5122
Using the Active Problem AnalyzerConfiguring APA
isEndNodeisFrameRelayisHSRPisIpPhoneisPartOfAggregatedIFisRouterisSnmpisSwitchslowIfSpeedsvlanTrunkPortwanIfTypes
2. Run the ovet_topodump.ovpl -node -filt ProcurveDevicescommand to get a list of all of the ProCurve devices in yourenvironment.
3. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
4. If the list of devices that this command produces contains thedevices you want to manage as a class, complete this step. AsAdministrator or root, open the paConfig.xml file and find thefollowing xml tags.
<classSpecifications>
<!-- Specify the parameters and the class of devices these
parameters are for. -->
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 topdown, so the order in which you add filters matters. Make sure youadd your filters before or after other filters as appropriate.
<classSpecification>
<filterName>ProcurveDevices</filterName>
<parameterList>
<parameter>
Chapter 5 123
Using the Active Problem AnalyzerConfiguring APA
<name>interval</name>
<title>Interval to Poll Device</title>
<description>
The interval which the device will be polled in seconds.
</description>
<varValue>
<varType>Integer</varType>
<value>300</value>
</varValue>
</parameter>
<parameter>
<name>snmpEnable</name>
<title>Enable polling via SNMP</title>
<description>
Enable/Disable polling of a device via SNMP.
</description>
<varValue>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
</parameterList>
</classSpecification>
Make sure to save your changes.
6. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
7. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
Chapter 5124
Using the Active Problem AnalyzerConfiguring APA
• UNIX: $OV_BIN/ovstart -c ovet_poll
Suppress or Allow APA Status Polling
You can configure NNM to allow or suppress the APA status polling ofobjects by using the ovet_toposet command.
Table 5-4 shows the effect on objects when allowing or suppressing APAstatus polling for nodes, boards, interfaces, or addresses.
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 couldoverride the ovet_toposet command, and suppress the polling of thetargeted object. See “Controlling Other APA Polling Types” on page 127for more information.
You can find the parameters used in the ovet_toposet command in theboard and interface information included in NNM AE’s Dynamic Views.See the ovet_toposet reference page (or the UNIX manpage) for moreinformation.
Table 5-4 Expected Object Status Behavior when Suppressing or AllowingAPA Status Polling
Allowed orSuppressed APAPolling of Object
APA Polling Behavior
Node Allows or suppresses APA status polling for the boardsassociated with a node, all of the interfaces associated witheach board, and the addresses associated with eachinterface.
Board Allows or suppresses APA status polling for the interfacesassociated with a board, and the addresses associated witheach interface.
Interface Allows or suppresses APA status polling for the addressesassociated with an interface.
Address Allows or suppresses APA status polling for the specifiedaddress.
Chapter 5 125
Using the Active Problem AnalyzerConfiguring APA
NOTE APA propagates the status of objects considered to be the root cause of afault to ovw.
APA may propagate the status of unpolled interfaces, objects notconsidered to be the root cause of a fault, or objects that do not exist inthe extended topology as having a normal or unknown status in ovw.
Chapter 5126
Using the Active Problem AnalyzerControlling Other APA Polling Types
Controlling Other APA Polling TypesThe Polling Engine section of the paConfig.xml file contains theconfiguration parameters for the ovet_poll process.This chapter onlyexplains a few of the modifications you can make to the Polling Engineand Status Analyzer. Do not make adjustments to the Talker or StatusBridge sections of the paConfig.xml file.
TIP You may find some basic knowledge of XML to be helpful when makingchanges to the filename.xml files discussed in this section. Changes youmake that are not discussed here are risky and unsupported.
You may need to modify the way APA polls devices and interfaces. To dothis, 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 filethat override any class-based parameters. For example, to enable ordisable global HSRP group polling, use the following procedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the following HSRP group polling enabling text:
<parameter>
<name>HSRPPollingEnable</name>
<title>Enable HSRP Polling</title>
<description>
Chapter 5 127
Using the Active Problem AnalyzerControlling Other APA Polling Types
Enable/Disable polling of HSRP Groups.
</description>
<varValue>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable the global HSRPpolling or true if you want to enable the global HSRP polling. Makesure to save your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
Enable or Disable HSRP Polling for Devices notBelonging to a Device Class
You may want to modify parameters for devices not belonging to a deviceclass. For example, to enable or disable HSRP group polling for routersand interfaces that do not belong to a device class, use the followingprocedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the following HSRP group polling enabling text:
Chapter 5128
Using the Active Problem AnalyzerControlling Other APA Polling Types
<parameter>
<name>hsrpEnable</name>
<title>Enable HSRP Polling</title>
<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>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable HSRP polling ortrue if you want to enable HSRP polling. This parameter enables ordisables HSRP polling for routers, ports, and interfaces. Make sure tosave your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
NOTE If you do not want APA polling your HSRP groups, runsetupExtTopo.ovpl and answer no when asked if you want to enableHSRP polling. You must run setupExtTopo.ovpl as Administrator orroot.
Chapter 5 129
Using the Active Problem AnalyzerControlling Other APA Polling Types
Enable or Disable SNMP Polling of Devices notBelonging to a Device Class
This an example of adjustable parameters for devices not belonging to adevice class. For example, to enable or disable SNMP polling for devicesthat do not belong to a device class, use the following procedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
2. As Administrator or root, edit the paConfig.xml file.
3. Look for the following SNMP polling enabling text:
<classSpecificParameters>
<!-- Default parameters for when no class of device is specified. -->
<defaultParameters>
<parameterList>
<parameter>
<name>interval</name>
<title>Interval to Poll Device</title>
<description>
The interval which the device will be polled in seconds.
</description>
<varValue>
<varType>Integer</varType>
<value>300</value>
</varValue>
</parameter>
<parameter>
<name>snmpEnable</name>
Chapter 5130
Using the Active Problem AnalyzerControlling Other APA Polling Types
<title>Enable polling via SNMP</title>
<description>
Enable/Disable polling of a device via SNMP.
</description>
<varValue>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable SNMP pollingfor devices that do not belong to a device class, or true if you want toenable SNMP polling for devices that do not belong to a device class.Make sure to save your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Enable or Disable ICMP Polling of Devices notBelonging to a Device Class
This an example of adjustable parameters for devices not belonging to adevice class. For example, to enable or disable ICMP polling for devicesthat do not belong to a device class, use the following procedure:
1. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
Chapter 5 131
Using the Active Problem AnalyzerControlling Other APA Polling Types
2. As Administrator or root, edit the paConfig.xml file.Create abackup copy of the paConfig.xml file prior to making any changes.
3. Look for the following SNMP polling enabling text:
<classSpecificParameters>
<!-- Default parameters for when no class of device is specified. -->
<defaultParameters>
<parameterList>
<parameter>
<name>interval</name>
<title>Interval to Poll Device</title>
<description>
The interval which the device will be polled in seconds.
</description>
<varValue>
<varType>Integer</varType>
<value>300</value>
</varValue>
</parameter>
<parameter>
<name>snmpEnable</name>
<title>Enable polling via SNMP</title>
<description>
Enable/Disable polling of a device via SNMP.
</description>
<varValue>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
<parameter>
Chapter 5132
Using the Active Problem AnalyzerControlling Other APA Polling Types
<name>pingEnable</name>
<title>Enable polling via ICMP</title>
<description>
Enable/Disable polling of a device via ICMP.
</description>
<varValue>
<varType>Bool</varType>
<value>true</value>
</varValue>
</parameter>
Modify the bold true to false if you want to disable ICMP polling fordevices that do not belong to a device class, or true if you want toenable ICMP polling for devices that do not belong to a device class.Make sure to save your changes.
4. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
5. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Enable or Disable SNMP Polling for UnconnectedSwitch Ports
There are times when some devices will not be in the extended topologydatabase, or will not otherwise connect correctly. An example of this is ifExtended Topology discovers information from an OAD environment, butcannot talk to some of the end nodes using SNMP. The result is confusionabout whether there are any nodes connected to certain ports on aswitch.
APA provides a solution for this problem. APA decides whether to poll adevice using attributes from the node and interface. For example, APAknows if an interface’s port is connected to another node in the extended
Chapter 5 133
Using the Active Problem AnalyzerControlling Other APA Polling Types
topology and knows the class of the device it is polling. You can configureAPA to SNMP poll switch ports that are either known to be connected toanother node in the extended topology or have an ifAdminStatus of up.
This solution involves editing the paConfig.xml file. This solutionassumes that you manually configure the ifAdminStatus parameter onthe 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.
3. Create a backup copy of the paConfig.xml file prior to making anychanges.
CAUTION Be sure to keep careful records and backups of any and all changes tothe paConfig.xml file.
4. As Administrator or root, edit the following file:
• Windows: %OV_CONF%\nnmet\paConfig.xml
• UNIX: $OV_CONF/nnmet/paConfig.xml
5. Search for UnconnectedAdminUpOrTestSwitchIF
You should see the following:
<classSpecification>
<filterName>UnconnectedAdminUpOrTestSwitchIF</filterName>
<parameterList>
<parameter>
<name>snmpEnable</name>
<title>Enable polling via SNMP</title>
<description>
Enable/Disable polling of a device via SNMP.
</description>
Chapter 5134
Using the Active Problem AnalyzerControlling Other APA Polling Types
<varValue>
<varType>Bool</varType>
<value>false</value>
</varValue>
</parameter>
6. Modify the bold false to true. Make sure to save your changes.
7. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
8. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Disable ICMP Polling for ISDN, SLIP, and OtherifTypes
Suppose you want to stop APA from using ICMP polling for IANAifTypes ISDN (ifType=20) and SLIP (ifType = 28). To do this, you can usean existing topology filter designed for ISDN and SLIP ifTypes. Ifdesired, you can expand the filter to include more ifTypes. To enable thisfeature, 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
Using the Active Problem AnalyzerControlling Other APA Polling Types
<ifType>28</ifType>
</attribute>
<attribute>
<ifType>20</ifType>
</attribute></operator>
</interfaceAssertion>
NOTE Notice the text in the bold font that sets the ifTypes within thisfilter. If you follow the rest of this procedure, APA will stop usingICMP polling for ISDN, SLIP, or other IANA ifTypes that youspecify.
3. If you want APA to stop using ICMP polling for additional IANAifTypes, add all of these new ifTypes using the same syntax shownin the above program listing. Add these additional ifTypes as shownbelow:
<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 syntaxof 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.xmlfile. If you cannot find the errors you made, replace theTopoFilters.xml file with the backup copy you made in step 1 andbegin again.
Chapter 5136
Using the Active Problem AnalyzerControlling Other APA Polling Types
5. Create a backup copy of the following file prior to making anychanges.
• Windows: %OV_CONF%\nnmet\paConfig.xml
• UNIX: $OV_CONF/nnmet/paConfig.xml
6. As Administrator or root, edit the paConfig.xml file.
7. Look for the following text:
<!-- Uncomment this class specification to disable ICMP (ping)
for IFTypeFilter. Users should edit the TopoFilters.xml
file to specify what IFTypes to include in the filter.<classSpecification>
<filterName>IFTypeFilter</filterName>
<parameterList>
<parameter>
<name>pingEnable</name>
<title>Enable polling via ICMP</title>
<description>
Enable/Disable polling of a device via ICMP.
</description>
<varValue>
<varType>Bool</varType>
<value>false</value>
</varValue>
</parameter>
</parameterList>
</parameterList>
</classSpecification>
remove this line also to uncomment above class specification -->
8. Remove the bold text shown at both the top and the bottom of theabove program listing. Make sure to save your changes.
9. Run the ovet_topodump.ovpl -if -filt IFTypeFilter commandto get a list of all of the ProCurve devices in your environment.
Chapter 5 137
Using the Active Problem AnalyzerControlling Other APA Polling Types
10. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
11. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Disable APA from Polling Specific Nodes
Suppose you want to stop APA from polling specific nodes. To do this, usethe following procedure:
1. Create a backup copy of the following file prior to making anychanges:
• 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.
3. Look for the following text:
<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">
<!-- Wildcards are allowed. See commented examples below. -->
<!-- Examples to filter based on subnets. -->
<!--<DNSName>*mysubnet*</DNSName>-->
<!--<DNSName>hsrp*.mycompany.com</DNSName>-->
<!-- Examples to filter based on IPaddr range or in a given OAD. -->
<!--<IPv4><address>10.0.0.*</address><OADId>33</OADId></IPv4>-->
<!--<IPv4><address>0.0.0.0-66</address></IPv4>-->
<!-- The following is a default sample. -->
<!-- Applicable network addresses should be supplied. -->
Chapter 5138
Using the Active Problem AnalyzerControlling Other APA Polling Types
<IPv4><address>0.0.0.0</address></IPv4>
</HostIDs>
4. Add the IP addresses you do not want APA to poll by using thesyntax and associated xml tags shown in the bold font in theprogram listing shown above. You can use wildcards or ranges asshown in the examples. Make sure to save your changes.
5. Create a backup copy of the following file:
• Windows: %OV_CONF%\nnmet\paConfig.xml
• UNIX: $OV_CONF/nnmet/paConfig.xml
6. As Administrator or root, edit the paConfig.xml file.
7. Look for the following text:
<!-- Uncomment this class specification to use the APANoPollNodes
filter. Users should edit the APANoPollNodes.xml
file to specify what nodes are in the filter.<classSpecification>
<filterName>APANoPollNodes</filterName>
<parameterList>
<parameter>
<name>snmpEnable</name>
<title>Enable polling via SNMP</title>
<description>
Enable/Disable polling of a device via SNMP.
</description>
<varValue>
<varType>Bool</varType>
<value>false</value>
</varValue>
</parameter>
<parameter>
<name>pingEnable</name>
<title>Enable polling via ICMP</title>
Chapter 5 139
Using the Active Problem AnalyzerControlling Other APA Polling Types
<description>
Enable/Disable polling of a device via ICMP.
</description>
<varValue>
<varType>Bool</varType>
<value>false</value>
</varValue>
</parameter>
<parameter>
<name>hsrpEnable</name>
<title>Enable HSRP Polling</title>
<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>
<varType>Bool</varType>
<value>false</value>
</varValue>
</parameter>
</parameterList>
</classSpecification>
remove this line also to uncomment above class specification -->
8. Remove the bold text shown at both the top and the bottom of theabove program listing. Make sure to save your changes.
9. Look for the following text:
<!-- Uncomment this class specification to use the APANoPollNodes
filter. Users should edit the APANoPollNodes.xml
file to specify what nodes are in the filter.<classSpecifications>
Chapter 5140
Using the Active Problem AnalyzerControlling Other APA Polling Types
<classSpecification>
<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>
<varType>Bool</varType>
<value>false</value>
</varValue>
</parameter>
</parameterList>
</classSpecification>
</classSpecifications>
remove this line also to uncomment above class specification -->
10. Remove the bold text shown at both the top and the bottom of theabove program listing. Make sure to save your changes.
11. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
12. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Chapter 5 141
Using the Active Problem AnalyzerControlling Other APA Polling Types
Disable APA from Using ICMP to Poll SpecificAddresses
Suppose you want to stop APA from using ICMP to poll specificaddresses. To do this, you can use an existing topology filter bycompleting the following procedure:
1. Create a backup copy of the following file prior to making anychanges:
• 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.
3. Look for the following text:
<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>
Chapter 5142
Using the Active Problem AnalyzerControlling Other APA Polling Types
<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 shownabove. 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 aboveexamples.
5. There are several working examples in the program listing above. Ifyou need to remove any of these working examples, remove all of thetext between the <attribute> and </attribute> tags. You willneed to remove the <attribute> and </attribute> tags as well. Ifyou need to add more addresses, use the syntax shown below. Makesure to save your changes.
<attribute>
<IPAddress>
<IPv4>
<address>address syntax</address>
</IPv4>
</IPAddress>
Chapter 5 143
Using the Active Problem AnalyzerControlling Other APA Polling Types
</attribute>
6. Use the ovet_topodump.ovpl -lfilt command to check the syntaxof 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.xmlfile with the backup copy you made in step 1 and begin again.
7. Create a backup copy of the following file prior to making anychanges:
• Windows: %OV_CONF%\nnmet\paConfig.xml
• UNIX: $OV_CONF/nnmet/paConfig.xml
8. As Administrator or root, edit the paConfig.xml file.
9. Look for the following text:
<!-- Uncomment this class specification to disable ICMP (ping)
for NoPingAddresses filter. Users should edit the
TopoFilters.xml addresses to include in the filter.<classSpecification>
<filterName>NoPingAddresses</filterName>
<parameterList>
<parameter>
<name>pingEnable</name>
<title>Enable polling via ICMP</title>
<description>
Enable/Disable polling of a device via ICMP.
</description>
<varValue>
<varType>Bool</varType>
<value>false</value>
</varValue>
Chapter 5144
Using the Active Problem AnalyzerControlling Other APA Polling Types
</parameter>
</parameterList>
</classSpecification>
remove this line also to uncomment above class specification -->
10. Remove the bold text shown at both the top and the bottom of theabove program listing. Make sure to save your changes.
11. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstop -c ovet_poll
• UNIX: $OV_BIN/ovstop -c ovet_poll
12. As Administrator or root, run the following command:
• Windows: %OV_BIN%\ovstart -c ovet_poll
• UNIX: $OV_BIN/ovstart -c ovet_poll
Chapter 5 145
Using the Active Problem AnalyzerFrequently Asked Questions
Frequently Asked QuestionsWhen enabled, APA replaces several features normally provided by thenetmon process. Below is a list of frequently asked questions andanswers that describe APA features.
How does APA affect NNM performance?
Answer: APA is multi-threaded, suppresses secondary alarms, andgenerates one alarm for a failure’s root cause in most cases. This resultsin a faster polling engine.
How does APA derive node and interface status?
Answer: APA uses ICMP to determine address status. It separatesinterfaces from addresses in order to monitor interface status using bothICMP or SNMP.
What does APA do in an HSRP environment?
Answer: Extended Topology with the Advanced Routing SPI queries thedevices that participate in an HSRP group. These devices must supportthe HSRP protocol. APA retrieves specific HSRP MIB values that providethe actual HSRP roles and responsibilities of each device in the group.Using this information, APA generates HSRP alarms when HSRP statuschanges occur.
Does APA consider Spanning Tree Protocol (STP) whenanalyzing failures?
Answer: APA considers the effects of the STP when diagnosing the rootcause of unresponsive interfaces. It suppresses transient failures due tospanning tree reconvergence which results in fewer transient alarms.
Does APA consider meshed switches when diagnosing networkfaults?
Answer: APA analyzes meshed environments when calculating the rootcause of unresponsive interfaces.
Does APA use any of the layer 2 information from the netmonprocess?
Answer: APA uses the layer 2 connectivity information stored in theextended topology database. It is important to remember that APA stillrelies on the netmon process for device discovery.
Chapter 5146
Using the Active Problem AnalyzerFrequently Asked Questions
How do you configure SNMP information for APA?
Answer: APA uses the same SNMP configuration information as thenetmon 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 Topologydiscovers. For example, after Extended Topology initiates and completesa discovery, or you tell Extended Topology to discover a specific zone andit completes that discovery, APA immediately begins using this newinformation.
Chapter 5 147
Using the Active Problem AnalyzerFrequently Asked Questions
Chapter 5148
6 Syslog Integration
Chapter 6 149
Syslog IntegrationIntroducing the Syslog Integration Functionality
Introducing the Syslog IntegrationFunctionalityThe Syslog Integration functionality enables the management ofnetwork equipment from syslog messages. Certain types of networkequipment do not have SNMP traps nor supporting MIBs for all errorand warning conditions. For operators who require managing theseconditions, the Syslog Integration functionality provides the ability tomap syslog messages into SNMP traps for presentation or analysis.
Network Node Manager Advanced Edition includes out-of-the-boxconditions for which syslog messages are mapped to SNMP traps. Youcan add new conditions through the NNM Syslog Trap MappingConfiguration interface or the HP OpenView Operations message sourcetemplate configuration windows, depending on your deployment mode.
Syslog Integration functionality is available with Network NodeManager Advanced Edition (NNM AE). Syslog Integration is alsoavailable with HP OpenView Operations with NNM, version 8.0. SyslogIntegration must be configured on an NNM management stationrunning an UNIX® operating system. See the Release Notes forsupported software versions.
Syslog Integration Deployment Options
There are two deployment options available to you when using theSyslog Integration functionality.
• NNM standalone
• OpenView Operations (OVO) with NNM
NOTE For the OVO with NNM deployment option, two scenarios areallowed. The Syslog Integration functionality resides on a NNMmanagement station co-located with OVO or the Syslog Integrationfunctionality resides on a remote NNM management station (notco-located with OVO).
Chapter 6150
Syslog IntegrationIntroducing the Syslog Integration Functionality
NNM Standalone Configuration
The NNM standalone configuration consists of deploying an HPOpenView Operations (OVO) agent on the NNM management station. Inshort, the embedded OVO agent uses preconfigured templates to parseincoming syslog messages matching a certain pattern. The matchedsyslog messages are mapped to SNMP traps and forwarded to NNM to bedisplayed in the NNM alarm browser. See Figure 6-1 on page 152 for anillustration.
In this approach, the following components comprise the heart of thearchitecture:
• The embedded OVO agent
When Syslog Integration is configured, an OVO agent is installed onthe NNM management station. Part of the embedded OVO agent isthe logfile encapsulator that is responsible for listening for syslogevents from logfiles. The logfile encapsulator filters and formatssyslog events according to information in configured templates. Thelogfile encapsulator then forwards relevant information in the formof messages to an NNM background process, syslogTrap, whichmaps the syslog messages into SNMP traps.
• The NNM management station
When Syslog Integration is configured, the NNM managementstation receives formatted syslog messages from the embedded OVOagent. syslogTrap, a background process on the NNM managementstation, maps the syslog messages to OpenView SNMP traps. Thisprocess registers with the OVO agent at the message streaminterface and filters all messages of message type NNMsyslog_.
The events generated from syslogTrap are of type OV_Syslog_ andhave the same general format:
— A unique enterprise-specific ID to identify the syslog message.
— An OpenView application name varbind identifying the source assyslogTrap.
— A varbind identifying the source of the event.
— Varbinds identifying the card/port/interface, status, and so on, asappropriate.
— A varbind that encapsulates the original message.
Chapter 6 151
Syslog IntegrationIntroducing the Syslog Integration Functionality
The SNMP traps are then sent to the NNM postmaster process, pmd,where the traps can participate in correlation or analysis. Forexample, when the NNM Smart Plug-in for LAN/WAN Edge isinstalled, it provides advanced correlators for frame relay traps andsyslog messages. pmd forwards the formatted syslog messages to theNNM alarm browser.
• NNM alarm browser
Processed syslog messages are displayed in the Status Alarmcategory of the NNM alarm browser.
Figure 6-1 shows the flow of events for the NNM standaloneconfiguration. This illustration assumes that the router has beenconfigured to forward syslog events to the NNM management station.
Figure 6-1 Flow of Events for NNM Standalone Configuration
syslogd
OVO Agent
logfile
Syslog toNNMtemplate
LogfileEncapsulator
router
EnabledTemplateand AgentMSI
syslogTrap
NNM alarmbrowser
NNM Management Stationpmd
ASCII
OV SNMP trap
OV alarm
syslog messageOVO-like message
Chapter 6152
Syslog IntegrationIntroducing the Syslog Integration Functionality
To modify the Syslog to NNM template, use the NNM Syslog TrapMapping Configuration Interface as described on page 155.
OpenView Operations with NNM ConfigurationSS
The OVO with NNM configuration option consists of deploying HPOpenView Operations with Network Node Manager. Two deploymentapproaches exist for this configuration option. First, the NNMmanagement station on which the Syslog Integration functionality isinstalled resides on the OVO server. Optionally, the Syslog Integrationfunctionality resides on a NNM management station separate from theOVO server system.
With either approach, you install an OVO agent on the NNMmanagement station from the OVO server and use the OVO tools toconfigure 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 theNNM management station to process syslog messages. As an OVOadministrator, you use the OVO configuration tools to upload thesyslog message source templates to the OVO agent and synchronizethe OVO message source templates with NNM trapd.conf.
• NNM forwards the SNMP traps to either (or both) the OVO messagebrowser or the NNM alarm browser, depending on how messages areconfigured to be diverted through the system.
Figure 6-2 on page 154 shows the flow of events for the OVO with NNMconfiguration. This illustration assumes that the router is configured toforward syslog events to the NNM management station.
Chapter 6 153
Syslog IntegrationIntroducing the Syslog Integration Functionality
Figure 6-2 Flow of Events for OVO with NNM Configuration
To construct and modify the Syslog to NNM message source template,use the standard OVO template editor. To launch the OVO templateeditor, see “OVO Message Source Templates Window” on page 155.
Configuration Tools
This section describes the tools needed to configure the NNM SyslogIntegration functionality. The tools and steps required differ dependingon your deployment option.
syslogd
OVO Agent
logfile
Syslog toNNMtemplate
LogfileEncapsulator
router
NNM alarmbrowser
NNM ManagementStation
OVO messagebrowser
SNMPTrapstemplate
ovtrap2opcOVO Server
EnabledTemplateand AgentMSI
syslogTrap
pmd
OV alarm
OV SNMP event
syslog messageASCII OVO-like message
Chapter 6154
Syslog IntegrationIntroducing the Syslog Integration Functionality
NNM Syslog Trap Mapping Configuration Interface
When you deploy the NNM standalone configuration option, youconstruct and modify the Syslog Integration message source templateconditions 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 Configurationinterface, see the Syslog Trap Mapping Configuration Online Help.
OVO Message Source Templates Window
When you deploy the OVO with NNM configuration option, you constructand modify Syslog Integration message source template conditionsthrough the Message Source Templates configuration window.
To open the Message Source Templates configuration window, launchthe OVO administrator interface ($OV_BIN/OpC/opc) and then clickWindow:Message Source Templates.
For instructions on how to use the Message Source Templatesconfiguration window, see the OVO Administrator Online Help.
Syslog Configuration Command
The Syslog Integration functionality is not enabled when NNM isinstalled. To enable and deploy a syslog configuration, use the commandline script, setupSyslog.ovpl.
Use the -help option to display a help message for thesetupSyslog.ovpl command options.
In the NNM Standalone Deployment Mode When the NNMstandalone configuration option is deployed, execute the syslogconfiguration 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 IntegrationIntroducing the Syslog Integration Functionality
For detailed configuration steps, see “Configuring Syslog Integration forNNM Standalone” on page 161.
The setupSyslog.ovpl configuration command is also used to deploynew syslog configurations. After editing syslog message source templateconditions with the Syslog Trap Mapping Configuration interface,execute setupSyslog.ovpl -standalone -deploy to deploy the newconfiguration. The -deploy command option generates and encrypts thenew template and restarts the embedded OVO agent so that the newtemplate is reloaded.
In the OVO with NNM Deployment Mode When the OVO withNNM configuration option is deployed, execute the syslog configurationcommand with the -server option by typing: setupSyslog.ovpl-server
This command creates an uploadable template configuration directoryfor the out-of-the-box syslog template, Syslog to NNM.
After executing this command, you must perform the followingconfiguration 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 agentinstalled on the NNM management station.
For detailed configuration steps, see “Configuring Syslog Integration forOVO with NNM on the Same System” on page 163.
Default Syslog Trap Mappings
NNM includes out-of-the-box template conditions for which syslogmessages are mapped to OpenView SNMP traps. Each type of syslogmessage to be mapped is defined in one template condition. Theconditions are contained in the Syslog to NNM template.
The Syslog to NNM template includes out-of-the-box message conditiondefinitions to match the following types of messages:
• Link Down and Link Up messages
• Line Protocol messages
Chapter 6156
Syslog IntegrationIntroducing the Syslog Integration Functionality
• Frame relay messages
• HSRP messages
• OSPF messages
• Trunk (port aggregation) messages, including Port AggregationProtocol (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 messagemappings. 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 IntegrationIntroducing the Syslog Integration Functionality
%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
%SYS-3-MOD_CFGMISMATCH2 OV_Syslog_Card_Config_Mismatch
%SYS-3-MOD_CFGMISMATCH3 OV_Syslog_Card_Config_Mismatch
%SYS-3-MOD_CFGMISMATCH4 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 cardmessages)
OV_Syslog_Card_Default_Message
%DTP (all other %DTP trunk messages) OV_Syslog_Trunk_Default_Message
%SPANTREE OV_Syslog_Spantree_Default_Message
Table 6-1 Syslog Trap Mappings (Continued)
Syslog Message OpenView Event Generated
Chapter 6158
Syslog IntegrationIntroducing the Syslog Integration Functionality
%CDP OV_Syslog_CDP_Default_Message
%BGP OV_Syslog_BGP_Default_Message
Table 6-1 Syslog Trap Mappings (Continued)
Syslog Message OpenView Event Generated
Chapter 6 159
Syslog IntegrationConfiguring Syslog Integration
Configuring Syslog IntegrationThis chapter provides the steps necessary to setup the Syslog Integrationfunctionality in either the NNM standalone deployment mode or OVOwith NNM deployment mode.
Prerequisites for Configuring Syslog
DCE Software Requirements for Syslog
IMPORTANT Installation of DCE software is required only for NNM standalonedeployments.
IMPORTANT Installation of DCE software prerequisites are required only for HP-UX11.0 operating systems. On HP-UX 11.11 or higher and Solaris operatingsystems, 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 HPOpenView Operations (OVO) agent on the NNM management station.The OVO agent requires two pieces of software to be installed prior toconfiguring syslog: DCE RPC and DCE-KT-Tools. See the Release Notesfor more information about supported software versions.
The required DCE software is available on the HP-UX ApplicationSoftware CD-ROMs. To install the required DCE software, do thefollowing:
1. Invoke the SD Install interface by typing: swinstall
2. Change the software view by clicking: View:Change SoftwareView->Start with Products.
3. Install the first DCE software package by selectingDCE-Core.DCE-CORE-RUN and clicking Actions:Install.
Chapter 6160
Syslog IntegrationConfiguring 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 DCEsoftware, 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 configurationdeployments.
If the NNM management station being used for syslog monitoring is aNetwork Information Service (NIS or NIS+) client, you need to installthe default OVO user, opc_op, and user group, opcgrp, on the NISserver.
If the default OVO user, opc_op, and user group, opcgrp, are notinstalled on the NIS server, or at least installed locally on the managednode, you may get errors when installing agents and agent software onthe managed node.
To add opc_op locally on the managed node, edit the /etc/passwd file toinclude an entry for opc_op. For example, the entry in the /etc/passwdfile 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 theSyslog Integration functionality. See “DCE Software Requirements forSyslog” on page 160.
Chapter 6 161
Syslog IntegrationConfiguring Syslog Integration
The Syslog Integration functionality is not enabled when NNMAdvanced Edition is installed. To enable and deploy a syslogconfiguration, use the command line script, setupSyslog.ovpl.
To enable Syslog Integration for NNM standalone configurations,execute the following command on the NNM management server:setupSyslog.ovpl -standalone
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 theSyslog to NNM Template” on page 162. For information about verifyingyour 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 TrapMapping Configuration interface. To launch the Syslog Trap MappingConfiguration interface, execute:
$OV_BIN/ovsyslogcfg
For instructions on how to use the Syslog Trap Mapping Configurationinterface, 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 itsconditions, see “Understanding the Syslog to NNM Template” onpage 177.
Testing Syslog Integration
Use the UNIX command line tool, logger, to write test messages to thesystem logfile. Read its man page for more information on how to use thecommand.
For example, to create a Line Protocol status Down syslog entry, do thefollowing:
HP-UX: logger %LINEPROTO-5-UPDOWN: Line protocol onInterface interface2, changed state to down
Chapter 6162
Syslog IntegrationConfiguring Syslog Integration
Solaris: logger -p user.err %LINEPROTO-5-UPDOWN: Line protocolon Interface interface2, changed state to down
When Syslog Integration is enabled, you should see syslog messagesmatching the conditions of the Syslog to NNM template forwarded to theNNM 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 onthe Same System
IMPORTANT If you are installing OVO on top of an NNM installation, be sure todisable Syslog Integration functionality prior to installing OVO. Forinstructions on disabling the Syslog Integration functionality, see“Removing Syslog Integration” on page 171.
The Syslog Integration functionality is not enabled when NNM isinstalled.
To enable and deploy a syslog configuration, do the following on theNNM management station:
1. Execute: setupSyslog.ovpl -server
Chapter 6 163
Syslog IntegrationConfiguring Syslog Integration
This command creates an uploadable template configurationdirectory for the out-of-the-box syslog template, Syslog to NNM,under /var/opt/OV/share/tmp/NNMsyslogTraps. This commandalso creates the syslog process, syslogTrap.
2. Register the syslogTrap process with NNM by executing thefollowing the commands:
a. Optional: Verify that the syslogTrap process is not alreadyregistered. Open the $OV_CONF/ovsuf file and check to see if thesyslogTrap process is listed. If not, proceed with theregistration.
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 bytyping:
opccfgupld NNMsyslogTraps
4. As user root, start HP OpenView Operations by typing:$OV_BIN/OpC/opc
Since the NNM process, syslogTrap, relies on message streaminterface (MSI) to map syslog messages to SNMP traps, the MSImust 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 NNMmanagement station, do the following:
Chapter 6164
Syslog IntegrationConfiguring Syslog Integration
a. From the Node Bank, select the node containing the OVO agentcoexisting 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 Outputfrom 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 onthe NNM management station by doing the following:
a. From the Node Bank, select the node containing the OVO agentcoexisting on the NNM management station.
b. Click Actions:Agents->Assign Templates. This opens theDefine Configuration window.
c. Click [Add]. The Add Configuration window displays.
d. Click [Open Template Window].
e. From the Message Source Templates window, select the Syslogto NNM template.
f. From the Add Configuration window, click [Get TemplateSelections].
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 onthe NNM management station by doing the following:
a. From the Node Bank, select the node containing the OVO agentcoexisting on the NNM management station.
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 TargetNodes pane.
d. Check Templates in the Components pane.
Chapter 6 165
Syslog IntegrationConfiguring Syslog Integration
e. Click [OK] to cause the template to be deployed on the managednode. Afterwards, you should see a message in the OVO messagebrowser 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 thiscommand.
• Check y when prompted to upload to SNMP Traps template.
• Install the SNMP Traps template on the OVO agent coexisting onthe NNM management station. For instructions on how to installtemplates on a managed node, see step 7 on page 165.
11. Optional: Test your syslog configuration by sending sample syslogmessages through the system. For instructions, see “Testing SyslogIntegration” 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,syslog.log, that the Syslog to NNM template monitors is set to/var/adm/messages.
Testing Syslog Integration
Use the UNIX command line tool, logger, to write messages to thesystem logfile. Read its man page for more information on how to use thecommand.
For example, to create a Line Protocol status Down syslog entry, do thefollowing:
HP-UX: logger %LINEPROTO-5-UPDOWN: Line protocol onInterface interface2, changed state to down
Solaris: logger -p user.err %LINEPROTO-5-UPDOWN: Line protocolon Interface interface2, changed state to down
Chapter 6166
Syslog IntegrationConfiguring Syslog Integration
When Syslog Integration is enabled, you should see syslog messagesmatching the conditions of the Syslog to NNM template forwarded to theNNM alarm browser or the OVO message browser, depending on yourconfiguration.
NOTE If you do not see syslog messages displayed in the NNM alarm browser,follow the troubleshooting tips outlined in “Not Seeing Syslog Messagesin Message Browser” on page 193.
NOTE SNMP trap definitions can be modified for testing purposes. Afterchanging SNMP trap definitions, execute the ovtrap2opc command. Forinstructions, see step 10 on page 166.
Configuring Syslog Integration for OVO with NNM onSeparate Systems
IMPORTANT If you are installing OVO on top of an NNM installation, be sure todisable Syslog Integration functionality prior to installing OVO. Forinstructions on disabling the Syslog Integration functionality, see“Removing Syslog Integration” on page 171.
The Syslog Integration functionality is not enabled when NNM isinstalled.
To enable and deploy a syslog configuration, do the following on theNNM management station:
1. From the OVO server, execute:
setupSyslog.ovpl -server
This command creates an uploadable template configurationdirectory for the out-of-the-box syslog template, Syslog to NNM,under /var/opt/OV/share/tmp/NNMsyslogTraps. This commandalso creates the syslog process, syslogTrap.
Chapter 6 167
Syslog IntegrationConfiguring Syslog Integration
2. From the OVO server, upload the Syslog to NNM template into theOVO 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 thesyslogTrap process with NNM by executing the following thecommands:
a. Optional: Verify that the syslogTrap process is not alreadyregistered. Open the $OV_CONF/ovsuf file and check to see if thesyslogTrap process is listed. If not, proceed with theregistration.
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 Operationsby typing: $OV_BIN/OpC/opc
Since the NNM process, syslogTrap, relies on message streaminterface (MSI) to map syslog messages to SNMP traps, the MSImust 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].
Chapter 6168
Syslog IntegrationConfiguring Syslog Integration
8. To enable the MSI on the OVO agent coexisting on the NNMmanagement station, do the following:
a. From the Node Bank, select the node containing the OVO agentcoexisting 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 Outputfrom 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 onthe NNM management station by doing the following:
a. From the Node Bank, select the node containing the OVO agentcoexisting on the NNM management station.
b. Click Actions:Agents->Assign Templates. This opens theDefine Configuration window.
c. Click [Add]. The Add Configuration window displays.
d. Click [Open Template Window].
e. From the Message Source Templates window, select the Syslogto NNM template.
f. From the Add Configuration window, click [Get TemplateSelections].
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 onthe NNM management station by doing the following:
a. From the Node Bank, select the node containing the OVO agentcoexisting on the NNM management station.
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 TargetNodes pane.
Chapter 6 169
Syslog IntegrationConfiguring Syslog Integration
d. Check Templates in the Components pane.
e. Click [OK] to cause the template to be deployed on the managednode. Afterwards, you should see a message in the OVO messagebrowser 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 thiscommand.
• Check y when prompted to upload to SNMP Traps template.
• Install the SNMP Traps template on the OVO agent coexisting onthe NNM management station. For instructions on how to installtemplates on a managed node, see step 9 on page 169.
13. Optional: Test your syslog configuration by sending sample syslogmessages through the system. For instructions, see “Testing SyslogIntegration” on page 170.
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,syslog.log, that the Syslog to NNM template monitors is set to/var/adm/messages.
Testing Syslog Integration
Use the UNIX command line tool, logger, to write messages to thesystem logfile. Read its man page for more information on how to use thecommand.
For example, to create a Line Protocol status Down syslog entry, do thefollowing:
HP-UX: logger %LINEPROTO-5-UPDOWN: Line protocol onInterface interface2, changed state to down
Chapter 6170
Syslog IntegrationConfiguring Syslog Integration
Solaris: logger -p user.err %LINEPROTO-5-UPDOWN: Line protocolon Interface interface2, changed state to down
When Syslog Integration is enabled, you should see syslog messagesmatching the conditions of the Syslog to NNM template forwarded to theNNM alarm browser or the OVO message browser, depending on yourconfiguration.
NOTE If you do not see syslog messages displayed in the NNM alarm browser,follow the troubleshooting tips outlined in “Not Seeing Syslog Messagesin Message Browser” on page 193.
NOTE SNMP trap definitions can be modified for testing purposes. Afterchanging SNMP trap definitions, execute the ovtrap2opc command. Forinstructions, see step 12.
Removing Syslog Integration
Removing Network Node Manager from the system does not completelyremove Syslog Integration. The OVO agent is left enabled and runningon the system.
To remove the remaining Syslog Integration components, do thefollowing:
1. Disable the Syslog Integration feature by executing the followingcommand:
For NNM standalone configurations, type:setupSyslog.ovpl -standalone -disable
For OVO with NNM configurations, type:setupSyslog.ovpl -server -disable
2. For NNM standalone configurations, remove the OVO agentsoftware 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 IntegrationConfiguring Syslog Integration
b. Select the ITOAgent software package name from the Name list.
c. Click Actions:Remove to remove the OVO agent from the NNMmanagement station.
Chapter 6172
Syslog IntegrationCustomizing Message Source Templates
Customizing Message Source TemplatesThis section provides the steps necessary to create, modify, and enableSyslog Integration message source templates. The configuration toolsused to modify message source templates are also described.
Overview of Message Source Templates
OVO agents are configured via message source templates. The OVOagent can only format and forward a message that is described in amessage source template.
In the NNM standalone configuration, the OVO agent is embedded onthe NNM management station. In the OVO with NNM configuration, theOVO agent coexists on the NNM management station. In either case, theOVO agent is configured to monitor the status of and collect informationfrom syslog messages through the Syslog to NNM message sourcetemplate.
Message source templates work by identifying strings within messagesin message streams. When messages match the conditions defined in themessage source templates, they are processed according to the rulesdefined in the template. When the Syslog Integration functionality isenabled, messages matching markers defined in the Syslog to NNMtemplate are forwarded to the NNM syslogTrap process. This processmaps 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. Inthe case of the Syslog to NNM template, the message source is alogfile.
• Message conditions and suppress conditions that match a set ofattributes and define responses to received messages. Theseconditions filter incoming messages from the message source. Theconditions also determine how the “important” messages aredisplayed in the operator window.
• Options, such as default message logging.
Chapter 6 173
Syslog IntegrationCustomizing Message Source Templates
Understanding the Template Configuration Tools
There are two main template editing tools used to create and modifysyslog configuration template conditions. For NNM standaloneconfigurations, 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 SourceTemplates window (see “OVO Message Source Templates Window” onpage 176). Details on how to use these template editing tools can befound in their respective online help volumes.
NNM Syslog Trap Mapping Configuration Interface
When the NNM standalone configuration option is deployed, youconstruct and modify Syslog Integration message source templateconditions 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 isshown in Figure 6-4 on page 175. This dialog supports the followingactions:
• 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. Theseconditions are explained in greater detail in “Understanding the Syslogto NNM Template” on page 177.
For instructions on how to use the Syslog Trap Mapping Configurationinterface, see the Syslog Trap Mapping Configuration Online Help.
Chapter 6174
Syslog IntegrationCustomizing Message Source Templates
Figure 6-4 Syslog Trap Mapping Configuration Dialog
Chapter 6 175
Syslog IntegrationCustomizing Message Source Templates
OVO Message Source Templates Window
When the OVO with NNM configuration option is deployed, youconstruct and modify Syslog Integration message source templateconditions through the Message Source Templates configurationwindow.
To open the Message Source Templates configuration window, launchHP OpenView Operations ($OV_BIN/OpC/opc) as an Administrator andthen click Window:Message Source Templates.
The Message Source Templates window is shown in Figure 6-5 onpage 176. The Syslog to NNM template for HP-UX operating systemsand Syslog to NNM (Solaris) template for Solaris operating systemscontain the conditions that map syslog message to OpenView SNMPtraps.
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:
Chapter 6176
Syslog IntegrationCustomizing Message Source Templates
• 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 syslogmessages are mapped to OpenView SNMP traps. Each type of syslogmessage to be mapped is defined in one template condition. Theconditions 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 OVOMessage and Suppress Conditions window.
Chapter 6 177
Syslog IntegrationCustomizing Message Source Templates
Figure 6-6 Syslog to NNM Template Conditions
Chapter 6178
Syslog IntegrationCustomizing Message Source Templates
In both the OVO template editor windows and the NNM Syslog TrapMapping Configuration interface, the order of the conditions is importantfor pattern matching. The patterns are tested in the order that they arelisted, and the first pattern to match is executed.
NOTE Since ordering of template conditions matters, it is important to placesuppression patterns first and more specific patterns at the beginning ofthe list. More general patterns should go last.
The first condition is a suppress unmatched condition, meaning thepattern will exclude any message that does not conform to its pattern. Inthis 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 notfunctionally perform anything, but is significant as an optimization tool,since all other conditions in this template will execute only on Ciscosyslog messages.
The remaining conditions look for Cisco syslog messages matchingdefined 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 IntegrationCustomizing Message Source Templates
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
Table 6-2 Template Conditions and Corresponding Syslog Messages
Template Condition Name Syslog Message Format
Chapter 6180
Syslog IntegrationCustomizing Message Source Templates
How Syslog to NNM Conditions Function in the NNMStandalone Configuration
Figure 6-7 shows a condition window to modify a Syslog to NNMtemplate condition definition. The window is divided into two logicalparts: a condition text field to match patterns and a set of attributes thatdefine the SNMP trap to be generated.
The Condition Text field uses syntax similar to a regular expression. Itidentifies the pattern to match and names any subexpressions in thepattern to be used in the mapping to an SNMP trap. See the NNM SyslogTrap Mapping Configuration Online Help for more information aboutpattern matching.
Syslog Trunk other %DTP
Syslog STP other %SPANTREE
Syslog CDP %CDP
Syslog BGP other message %BGP
Table 6-2 Template Conditions and Corresponding Syslog Messages
Template Condition Name Syslog Message Format
Chapter 6 181
Syslog IntegrationCustomizing Message Source Templates
Figure 6-7 Modify Message Condition Window for Syslog LINKDOWN
The Position field identifies the location of the condition with respect tothe 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 begenerated in response to a message matching the condition pattern.
The varbinds of the trap are defined in the lower table, as shown inFigure 6-7.
You can edit the Condition Text and the Trap OID fields. You can alsomodify and reorder any of the varbinds. See the NNM Syslog TrapMapping Configuration Online Help for more information aboutmodifying these fields.
Messages matching the pattern defined in the Condition Text fieldcause the OpenView event identified by the Trap OID to be generated.For example, when a %LINK-3-UPDOWN status DOWN message is logged tothe syslog file, the message is intercepted, since the Syslog LINKDOWN
Chapter 6182
Syslog IntegrationCustomizing Message Source Templates
condition looks for this pattern (as shown in the Condition Text field ofFigure 6-7). In that same condition, a trap OID is identified, whichcorresponds to the OpenView event, OV_Syslog_LinkDown, as shown inFigure 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 OpenViewevents 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 theEvent Configurator/Modify Event window. An example is shown inFigure 6-8 on page 184.
Chapter 6 183
Syslog IntegrationCustomizing Message Source Templates
Figure 6-8 OV_Syslog _LinkDown Event Configuration Window
How Syslog to NNM Templates Function in the OVOwith NNM Configuration
Figure 6-9 on page 185 shows a condition window to modify a Syslog toNNM template condition definition. The window is divided into threelogical parts: input section, condition matching section, and messageoutput section.
Chapter 6184
Syslog IntegrationCustomizing Message Source Templates
Figure 6-9 OVO Condition Editing Window
The top part contains the input section. Messages are matched accordingto 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 sourceof a message, such as software.hp.com.
254
Chapter 6 185
Syslog IntegrationCustomizing Message Source Templates
The matching conditions section describes how the conditions are to betreated. The options are listed in Table 6-4.
Message Text Content and/or description of a message.Use OVO’s regular expression-likesyntax to define the Message Text.
Right-click in the field to view a shortlist of acceptable regular expressions.For example, if you want to matchmessages on the string “Switch1”, thendefine the Message Text field to be<*>Switch1<*>.
See the OVO Administrator Online Helpfor more information on writing patternmatching expressions.
512
Table 6-3 Input Fields for OVO Template Conditions (Continued)
Field Description Size
Table 6-4 Matching Conditions for OVO TemplateConditions
Option Description
Suppress Matched Condition Suppresses all messagesmatching condition fields in theinput section. Messages arestored in a log file, rather thandisplaying in the OVO messagebrowser.
Identified by the – symbol.
Suppress Unmatched Condition Suppresses all messages notmatching condition fields in theinput section. Messages arestored in a log file, rather thandisplaying in the OVO messagebrowser.
Identified by the = symbol.
Chapter 6186
Syslog IntegrationCustomizing Message Source Templates
The lower portion contains the output section. The fields in this sectioncorrespond to columns in the message browser. Use these fields toreformat the original message into a more readable format for end users.When any of these fields are unspecified, values are copied from theoriginal message. Table 6-5 lists the key message fields, their intendedusage, and their size limitations.
NOTE If the value of an output field is a named subexpression from theMessage Text input field, it must be enclosed in angle brackets (<>).
Message on Matched Condition Forwards all messages matchingcondition fields in the inputsection to the OVO messagebrowser.
Identified by the + symbol.
Table 6-4 Matching Conditions for OVO TemplateConditions (Continued)
Option Description
Table 6-5 Output Fields of OVO Template Conditions
Field Description Size
Node Identifies the source of a message. Inthe Syslog to NNM templateconditions, the value of this field ispulled from the incoming syslogmessage. Its value is stored in thevariable node.
254
Application Medium-grained identifier for amessage source. For example, Oracle.
32
Message Group Group of alarms to which a messagebelongs.
32
Object Fine-grained message sourceidentifier. For example, Syslog.
32
Chapter 6 187
Syslog IntegrationCustomizing Message Source Templates
NOTE Be aware that Node, Application, Message Group, and Object fields areused by administrators to create filtered views in the OVO interface.Consistent use of these fields is paramount to enabling operators toeffectively monitor equipment for which they are responsible.
From the OVO condition editing window, as shown in Figure 6-9 onpage 185, you add, delete, or modify custom message attributes (CMAs).Custom message attributes allow you to add your own attributes to amessage. 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 CustomMessage Attributes window. To open, click [Custom Attributes] fromthe OVO condition editing window. For example, Figure 6-10 shows a listof defined custom message attributes for the syslog LINKDOWNcondition.
The Name field defines the name of the attribute that is displayed as anadditional column in the message browser. The Value field sets the valueof the attribute. A Value entry can contain either hard-coded text or avariable defined in the Message Text input field.
Message Text Contains the description text of amessage.
2048
Service Name Identifier used to associate a messagewith a service.
254
Message Type Identifier of a subgroup of a messagegroup. In order for syslog messages tobe forwarded to the NNMsyslogTrap process, NNMsyslog_ isrequired to be entered in this field.
32
Table 6-5 Output Fields of OVO Template Conditions (Continued)
Field Description Size
Chapter 6188
Syslog IntegrationCustomizing Message Source Templates
Figure 6-10 OVO Custom Message Attributes
If you have enabled the display of custom message attributes in yourOVO message browser, they appear as additional columns in your OVOmessage browser.
Chapter 6 189
Syslog IntegrationMaintaining Syslog Integration
Maintaining Syslog IntegrationThis section provides instructions for tasks that an NNM administratorwould need to perform to maintain the working of the Syslog Integrationfunctionality.
Administrative Tasks for NNM StandaloneConfigurations
Deploying Syslog to NNM Template
After editing syslog message source template conditions with the SyslogTrap Mapping Configuration interface, execute
setupSyslog.ovpl -standalone -deploy
to deploy the new configuration.
The -deploy command option generates and encrypts the new templateand restarts the embedded OVO agent so that the new template isreloaded.
Testing Patterns in Template Conditions
Before you redeploy the Syslog to NNM template, you can verify thesyntax of any template condition by executing:
opcpat
Read the man page for opcpat for instructions on how to use thecommand.
Disabling Syslog Integration Functionality
To disable the syslog functionality, execute:
setupSyslog.ovpl -standalone -disable
This command stops the embedded OVO agent processes and the NNMsyslogTrap process. The OVO agent software remains on the NNMmanagement station. To remove the OVO agent software, see “RemovingSyslog Integration” on page 171.
You can re-enable the Syslog Integration functionality, by executing:setupSyslog.ovpl -standalone
Chapter 6190
Syslog IntegrationMaintaining Syslog Integration
Administrative Tasks for OVO with NNMConfigurations
Disabling Syslog Integration Functionality
To disable the Syslog Integration functionality, execute:
setupSyslog.ovpl -server -disable
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 thesetupSyslog.ovpl configuration script. Therefore, you cannot start thisprocess until you have run the setupSyslog.ovpl script.
To stop the syslogTrap process, execute:
ovstop -c syslogTrap
Chapter 6 191
Syslog IntegrationTroubleshooting Tips
Troubleshooting TipsHere are some troubleshooting tips for the Syslog Integrationfunctionality.
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 volumesyslog message systems.
Some performance issues may arise as the syslog messages from themanaged network elements can become extremely abundant. Sufficienttuning of the Syslog to NNM template conditions may need to be donefor exclusion patterns to improve performance. Additionally, you mayneed 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 thefollowing:
• In OVO with NNM configurations, you must enable the messagestream interface for both the Syslog to NNM template and the OVOagent on the NNM management station in order for syslog messagesto be processed as documented. However, in OVO, there are amultitude of combinations for diverting messages through thesystem. For example, you can enable the message stream interfacefor individual conditions of a template to copy messages as well asenabling the message stream interface for the template to copymessages. This will produce multiple messages in the messagebrowser.
Chapter 6192
Syslog IntegrationTroubleshooting Tips
• Templates are not ordered, meaning that if messages matchconditions of multiple templates, multiple messages are displayed inthe message browser. For example, if a wildcard template is assignedand installed on a system, then every message entering the agent isforwarded to the message browser. Furthermore, if additionaltemplates are assigned and installed on a system, then thosemessages matching the conditions of the templates are alsoforwarded to the message browser. Thus, duplicate messages appearin the message browser, formatted according to rules in thetemplates.
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 OVOagent system (on the NNM management station). To verify that theSyslog 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 atemplate you have assigned to an agent node has successfully beeninstalled on that agent system.
Be aware that this command does not indicate which version of thetemplate has been deployed. If you have made modifications to anyassigned templates, you must reinstall the templates on themanaged nodes.
• For OVO with NNM configurations, the message stream interface isnot enabled for either the Syslog to NNM template or the OVO agenton the NNM management station.
To isolate the problem, you can turn on XPL tracing for thesyslogTrap process. If you see no activity in incoming messages, itusually means that the message stream interface has not beenenabled in all places that must be enabled.
• The templates are marked as log only. Use the NNM EventConfiguration window to change the logging state. From any NNMsubmap, select Options:Event Configuration.
• When APA is enabled, several correlators are added to HP OpenViewCorrelation Composer that listen for and correlate syslog messages.You may not see some syslog messages in the alarm browser because
Chapter 6 193
Syslog IntegrationTroubleshooting Tips
the APA-enabled correlators may discard the syslog messages or nestthem under APA status alarms. For a description of the APAcorrelators and how syslog messages take part in event reduction,see Chapter 7, “APA and Event Reduction,” on page 195.
Chapter 6194
7 APA and Event Reduction
Chapter 7 195
APA and Event ReductionNNM’s Event Reduction Capabilities When APA Is Enabled
NNM’s Event Reduction Capabilities WhenAPA Is EnabledNM includes a set of built-in correlators that are enabled out-the-box.These basic correlators are described in detail in the Event Reductionchapter of Managing Your Network.
This chapter explains additional NNM correlators that are enabled whenAPA is configured.
Correlation Composer and APA Correlators
The APA correlators are defined using HP OpenView CorrelationComposer.
NOTE The instructions and information provided within this chapter aredescribed using the operator mode of the HP OpenView CorrelationComposer user interface. For more information about HP OpenViewCorrelation Composer, see HP OpenView Correlation Composer’s Guide.
Syslog Integration and APA Correlators
Syslog Integration and APA are distinct pieces of functionality providedwith NNM Advanced Edition. Each can be enabled individually;however, the most benefit is achieved when Syslog Integration is enabledin conjunction with APA functionality.
Many of the correlators provided with APA work on syslog events. Forexample, certain syslog messages causes an immediate APA poll of thenetwork device identified in the message. Other correlators listen forsyslog messages and nest them beneath the appropriate APA alarm,enabling better root cause analysis.
For more information about the Syslog Integration functionality, seeChapter 7, “APA and Event Reduction,” on page 195.
Chapter 7196
APA and Event ReductionNNM’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 syslogcorrelators, see “Disabling APA Correlators and Correlator Groups” onpage 232.
Chapter 7 197
APA and Event ReductionOverview of APA Correlators
Overview of APA CorrelatorsThe APA-enabled correlators are logically divided into sevennamespaces: 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 andis interchangeable with other vendor terms, including card andmodule. For information on the board and port information that NNMExtended Topology can discover, see “Discovering Board and PortInformation on Cisco Devices” on page 21.
NOTE The term aggregated port is used within this chapter as the genericHP term and is interchangeable with the term trunk.
The OV_PollerIntermittent namespace contains a set of correlatorsthat notify you when a network component is flapping. When APA statuschange alarms or LinkDown/LinkUp transitions exceed a countthreshold 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 arereceived 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 andcreates a new node intermittent status alarm(OV_APA_NODE_Intermittent) when N APA node-down events arereceived from the same source within M minutes (defaults N=2,M=30 minutes).
Chapter 7198
APA and Event ReductionOverview of APA Correlators
• “Interface Intermittent Status Change” on page 205
Listens for OV_APA_IF_DOWN alarms from the APA poller and createsa new interface intermittent status alarm(OV_APA_IF_Intermittent) when N APA interface-down events arereceived 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 andcreates a new address intermittent status alarm(OV_APA_ADDR_Intermittent) when N APA address-down eventsare 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 pollerand creates a new connection intermittent status alarm(OV_APA_CONN_Intermittent) when N APA connection-down eventsare received within M minutes from the same source (defaults N=2,M=30 minutes).
The OV_PollerLinkDown namespace contains a set of correlators thatdetermine if the root cause of a LinkDown event is a result of a node orconnection going down. When appropriate, the LinkDown events arecorrelated under the APA root cause alarm and then removed from thealarm browser.
• “LinkDown Events and APA Node Status Alarms” on page 209
(a combination of two correlators) Correlates LinkDown events withAPA node-down alarms, OV_APA_NODE_DOWN. LinkDown eventsreceived within M minutes from the same source as the APA nodestatus alarm are suppressed and nested beneath the APA nodestatus alarm (default M=10 minutes).
• “LinkDown Events and APA Connection Status Alarms” on page 210
(a combination of two correlators) Correlates LinkDown events withAPA connection-down alarms, OV_APA_CONNECTION_DOWN orOV_APA_CONNECTION_UNREACHABLE. LinkDown events receivedwithin M minutes from the same source as the APA connectionstatus alarm are suppressed and nested beneath the APA connectionstatus alarm (default M=10 minutes).
Chapter 7 199
APA and Event ReductionOverview of APA Correlators
The OV_CiscoBoard namespace contains a set of correlators thatdetermine if LinkDown events and syslog Link Down and Line ProtocolDown messages are secondary events to Board Down (or ModuleDown)events. Secondary events are correlated under the root cause eventidentifying the board (or module) that failed.
• “LinkDown and Syslog Down Events with Board Down Events” onpage 212
(a combination of four correlators) Listens for LinkDown events,syslog Link Down messages, and syslog Line Protocol Downmessages as well as Board Down (or ModuleDown) events. Thecorrelators store the events based on the board (or module) ID andthe node ID extracted from the topology database.
These correlators nest secondary events, including LinkDown eventsand syslog Down events, beneath the Board Down event.
• “LinkDown and Syslog Down Events with Syslog Board DownEvents” on page 213
(a combination of four correlators) Listens for LinkDown events,syslog Link Downmessages, and syslog Line Protocol Down eventsas well as syslog Board Down (or ModuleDown) events. Thecorrelators store the events based on the board (or module) ID andthe node ID extracted from the topology database.
These correlators nest secondary events, such as LinkDown eventsand syslog Down events, beneath the syslog Board Down event.
• “Board Down and Syslog Board Down Events Correlator” onpage 214
The OV_Board_Trap_SyslogCorr correlator correlates Board Downevents and syslog Board Down messages. The first event to arrive isdisplayed in the alarm browser. Subsequent events are nested underthe first event. The correlator matches events based on the board (ormodule) ID.
The OV_PollerBoardDown namespace contains a set of correlators thatdetermine if Board Down events or syslog Board Down messages shouldbe nested under the root cause APA Board Down alarm. Whenappropriate, the Board Down events are correlated under the APA BoardDown alarm and then removed from the alarm browser.
• “Board Down Events with APA Board Failure Alarms” on page 216
Chapter 7200
APA and Event ReductionOverview of APA Correlators
(a combination of two correlators) Correlates Board Down(ModuleDown) events with APA Board Down alarms. The correlatorsmatch alarms based on the board (or module) ID and the node IDextracted from the topology database.
• “Syslog Board Down Events with APA Board Failure Alarms” onpage 217
(a combination of two correlators) Correlates syslog Board Downmessages with APA Board Down alarms. The correlators matchalarms based on the board (or module) ID and the node ID extractedfrom the topology database.
The OV_PollerTrigger namespace contain a set of correlators thattrigger an immediate APA poll and analysis of a network entity (of typenode, interface, board, or HSRP group). When certain types of traps orsyslog messages arrive, these correlators generate the appropriate APApoll trigger request on the network entity. Depending on the type ofevent, the correlators may issue a status poll request, a configurationpoll request, or a force poll request.
• “APA Poll Trigger Requests” on page 219
(a set of fourteen correlators) Generates an APA Demand Analysisalarm that triggers an immediate APA poll on the network entityspecified in the event. When no other events of the same event sourceand poll type have been sent to the APA poller within a specifiedtime period, the network entity is immediately polled.
The OV_PollerTriggerCorr namespace contains a set of correlatorsthat correlate duplicate poll trigger events not already being correlatedby the other APA correlators. Secondary events are correlated under thefirst event to arrive or under the APA alarm that is generated as a resultof the poll request.
• “OSPF Adjacency Change Events with APA Root Cause Alarms” onpage 224
(a set of two correlators) Correlates OSPF Adjacency Change eventswith the appropriate APA root cause alarm, OV_APAConnection or IFstatus alarms. OSPF Adjacency Change events received within aspecified time period from the same source as the APA root causealarm are suppressed and nested beneath the APA root cause alarm.
• “HSRP State Change Events with HSRP Root Cause Alarms” onpage 225
Chapter 7 201
APA and Event ReductionOverview of APA Correlators
(a set of two correlators) Correlates HSRP State Change events withthe appropriate APA root cause alarm, OV_HSRP_*. HSRP StateChange events received within a specified time period from the samesource as the APA root cause alarm are suppressed and nestedbeneath 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 Startevents as well as syslog RELOAD and RESTART messages with APAnode status alarms, OV_APA_NODE_UP. Events received within aspecified time period from the same source as the APA node statusalarm are suppressed and nested beneath the APA node statusalarm.
The OV_PollerPortAgg namespace contains a set of correlators thatdetermine if LinkDown events and syslog Down events as well as syslogport aggregation events are secondary events to APA port aggregationstatus alarms. Secondary events are correlated under the APA root causealarm.
• “LinkDown Events and Syslog Down Events with APA AggregatedPort 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 AggregatedPort alarms. The correlators store the events based on the node IDextracted from the topology database. LinkDown events and syslogDown events received within a specified time period matching thenode ID of the APA Aggregated Port alarm are suppressed andnested 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 andsyslog port aggregation (PAGP) events, which provide notification ofwhen a physical port has joined or left an aggregated port. Thecorrelator stores the syslog port aggregation events based on thenode ID extracted from the topology database. Syslog portaggregation events received within a specified time period matchingthe node ID of the APA Aggregated Port alarm are suppressed andnested beneath the APA Aggregated Port alarm.
Chapter 7202
APA and Event ReductionOV_PollerIntermittent Namespace
OV_PollerIntermittent NamespaceThe OV_PollerIntermittent namespace contains a set of correlatorsthat notify you when a network component is flapping. When APA statuschange alarms or LinkDown/LinkUp transitions exceed a countthreshold 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 flappingalarm and forwards the new alarm to the NNM alarm browser.
Behavior
The ECS PairWise correlation deletes LinkDown events from the NNmalarm browser when a LinkUp event arrives, unless configuredotherwise. Therefore, you may not see these events in the NNM alarmbrowser. The OV_Link_Intermittent correlator detects a repetitivelink-down situation and generates an OV_Link_Intermittent alarm towarn you of a potential problem.
If a LinkDown events arrives and no other LinkDown events have beenreceived from that same source, a new interval is started. If LinkDownevents already exist for that source, a counter is updated and checked tosee if its count exceeds the configured threshold (default, Count = 3). Ifthe count exceeds the threshold and the event is received within thecurrent interval (default, Window Period = 30 minutes), anOV_Link_Intermittent alarm is generated and forwarded to the NNMalarm browser. All further LinkDown events for that device within thetime interval are nested under the OV_Link_Intermittent alarm.
Configurable Parameters
The only configurable parameters, by default, are:
• Count
• Window Period
Chapter 7 203
APA and Event ReductionOV_PollerIntermittent Namespace
For instructions on how to modify these parameters, see “SettingParameters” on page 230. Note that the OV_Link_Intermittentcorrelator 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 correlatordetects a repetitive node down/up situation and generates anOV_APA_NODE_Intermittent alarm to warn you of a potential problem.
The OV_Node_IntermittentStatus correlator generates anOV_APA_NODE_Intermittent alarm if the OV_APA_NODE_DOWN eventoccurs a specified number of times (default, Count = 2) during a specifiedtime interval (default, Window Period = 30 minutes) from the samenode.
If an OV_APA_NODE_DOWN event arrives and no other OV_APA_NODE_DOWNevents have been received from that same node, a new interval isstarted. If OV_APA_NODE_DOWN events already exist for that node, acounter is updated and checked to see if its count exceeds the configuredthreshold. If the count exceeds the threshold and the event is receivedwithin the current interval, an OV_APA_NODE_Intermittent alarm isgenerated and forwarded to the NNM alarm browser. All furtherOV_APA_NODE_DOWN events for that node within the time interval arenested under the OV_APA_NODE_Intermittent alarm.
Note that, depending on how the ECS PairWise correlation isconfigured, you may not see OV_APA_NODE_DOWN and OV_APA_NODE_UPevents in the NNM alarm browser. However, you may see anOV_APA_NODE_DOWN event in the alarm browser at the same time as theOV_APA_NODE_Intermittent alarm. The OV_APA_NODE_DOWN eventremains in the alarm browser until the corresponding OV_APA_NODE_UPevent is generated and dismissed by the ECS PairWise correlation.
Configurable Parameters
The only configurable parameters, by default, are:
• Count
• Window Period
Chapter 7204
APA and Event ReductionOV_PollerIntermittent Namespace
For instructions on how to modify these parameters, see “SettingParameters” on page 230. Note that the OV_Node_IntermittentStatuscorrelator is contained within the OV_PollerIntermittent namespace.
Interface Intermittent Status Change
Identifies interfaces that are reporting intermittent up/down status.
Behavior
When APA is enabled, the OV_Interface_IntermittentStatuscorrelator detects a repetitive interface down/up situation and generatesan OV_APA_IF_Intermittent alarm to warn you of a potential problem.
The OV_Interface_IntermittentStatus correlator generates anOV_APA_IF_Intermittent alarm if the OV_APA_IF_DOWN event occurs aspecified number of times (default, Count = 2) during a specified timeinterval (default, Window Period = 30 minutes) from the same interface.
If an OV_APA_IF_DOWN event arrives and no other OV_APA_IF_DOWNevents have been received from that same interface, a new interval isstarted. If OV_APA_IF_DOWN events already exist for that interface, acounter is updated and checked to see if its count exceeds the configuredthreshold. If the count exceeds the threshold and the event is receivedwithin the current interval, an OV_APA_IF_Intermittent alarm isgenerated and forwarded to the NNM alarm browser. All furtherOV_APA_IF_DOWN events for that interface within the time interval arenested under the OV_APA_IF_Intermittent alarm.
Note that, depending on how the ECS PairWise correlation isconfigured, you may not see OV_APA_IF_DOWN and OV_APA_IF_UP eventsin the NNM alarm browser. However, you may see an OV_APA_IF_DOWNevent in the alarm browser at the same time as theOV_APA_IF_Intermittent alarm. The OV_APA_IF_DOWN event remainsin the alarm browser until the corresponding OV_APA_IF_UP event isgenerated and dismissed by the ECS PairWise correlation.
Configurable Parameters
The only configurable parameters, by default, are:
• Count
• Window Period
Chapter 7 205
APA and Event ReductionOV_PollerIntermittent Namespace
For instructions on how to modify these parameters, see “SettingParameters” on page 230. Note that theOV_Interface_IntermittentStatus correlator is contained within theOV_PollerIntermittent namespace.
Address Intermittent Status Changes
Identifies addresses that are reporting intermittent up/down status.
Behavior
When APA is enabled, the OV_Addr_IntermittentStatus correlatordetects a repetitive address down/up situation and generates anOV_APA_ADDR_Intermittent alarm to warn you of a potential problem.
The OV_Addr_IntermittentStatus correlator generates anOV_APA_ADDR_Intermittent alarm if the OV_APA_ADDR_DOWN eventoccurs a specified number of times (default, Count = 2) during a specifiedtime interval (default, Window Period = 30 minutes) from the sameaddress.
If an OV_APA_ADDR_DOWN event arrives and no other OV_APA_ADDR_DOWNevents have been received from that same address, a new interval isstarted. If OV_APA_ADDR_DOWN events already exist for that address, acounter is updated and checked to see if its count exceeds the configuredthreshold. If the count exceeds the threshold and the event is receivedwithin the current interval, an OV_APA_ADDR_Intermittent alarm isgenerated and forwarded to the NNM alarm browser. All furtherOV_APA_ADDR_DOWN events for that address within the time interval arenested under the OV_APA_ADDR_Intermittent alarm.
Note that, depending on how the ECS PairWise correlation isconfigured, you may not see OV_APA_ADDR_DOWN and OV_APA_ADDR_UPevents in the NNM alarm browser. However, you may see anOV_APA_ADDR_DOWN event in the alarm browser at the same time as theOV_APA_ADDR_Intermittent alarm. The OV_APA_ADDR_DOWN eventremains in the alarm browser until the corresponding OV_APA_ADDR_UPevent is generated and dismissed by the ECS PairWise correlation.
Configurable Parameters
The only configurable parameters, by default, are:
• Count
Chapter 7206
APA and Event ReductionOV_PollerIntermittent Namespace
• Window Period
For instructions on how to modify these parameters, see “SettingParameters” on page 230. Note that the OV_Addr_IntermittentStatuscorrelator is contained within the OV_PollerIntermittent namespace.
Connection Intermittent Status Change
Identifies connections that are reporting intermittent up/down status.
Behavior
When APA is enabled, the OV_Connection_IntermittentStatuscorrelator detects a repetitive connection down/up situation andgenerates an OV_APA_CONN_Intermittent alarm to warn you of apotential problem.
The OV_Connection_IntermittentStatus correlator generates anOV_APA_CONN_Intermittent alarm if the OV_APA_CONNECTION_DOWNevent occurs a specified number of times (default, Count = 2) during aspecified time interval (default, Window Period = 30 minutes) from thesame source.
If an OV_APA_CONNECTION_DOWN event arrives and no otherOV_APA_CONNECTION_DOWN events have been received from that samesource, a new interval is started. If OV_APA_CONNECTION_DOWN eventsalready exist for that source, a counter is updated and checked to see ifits count exceeds the configured threshold. If the count exceeds thethreshold and the event is received within the current interval, anOV_APA_CONN_Intermittent alarm is generated and forwarded to theNNM alarm browser. All further OV_APA_CONNECTION_DOWN events forthat source within the time interval are nested under theOV_APA_CONN_Intermittent alarm.
Note that, depending on how the ECS PairWise correlation isconfigured, you may not see OV_APA_CONNECTION_DOWN andOV_APA_CONNECTION_UP events in the NNM alarm browser. However,you may see an OV_APA_CONNECTION_DOWN event in the alarm browser atthe same time as the OV_APA_CONN_Intermittent alarm. TheOV_APA_CONNECTION_DOWN event remains in the alarm browser until thecorresponding OV_APA_CONNECTION_UP event is generated and dismissedby the ECS PairWise correlation.
Chapter 7 207
APA and Event ReductionOV_PollerIntermittent Namespace
Configurable Parameters
The only configurable parameters, by default, are:
• Count
• Window Period
For instructions on how to modify these parameters, see “SettingParameters” on page 230. Note that theOV_Connection_IntermittentStatus correlator is contained within theOV_PollerIntermittent namespace.
Chapter 7208
APA and Event ReductionOV_PollerLinkDown Namespace
OV_PollerLinkDown NamespaceThe OV_PollerLinkDown namespace contains a set of correlators thatdetermine if the root cause of a LinkDown event is a result of a node orconnection going down. When appropriate, the LinkDown events arecorrelated under the APA root cause alarm and then removed from thealarm browser.
LinkDown Events and APA Node Status Alarms
Listens for LinkDown events and OV_APA_NODE_DOWN alarms. LinkDownevents received within M minutes from the same source as the APA nodestatus alarm are suppressed and nested beneath the APA node statusalarm (default M=10 minutes).
Behavior
When APA is enabled, the OV_LinkDown_NodeDown correlator works withthe OV_Link_Down correlator in the following way:
1. The OV_Link_Down correlator listens for LinkDown events. When aLinkDown event arrives, the OV_Link_Down correlator generates anew, enhanced event, OV_Link_Down.
2. The OV_LinkDown_NodeDown correlator listens for OV_Link_Downevents and extracts the associated node IDs from these events.
3. The OV_LinkDown_NodeDown correlator waits for anOV_APA_NODE_DOWN event to arrive. When an OV_APA_NODE_DOWNevent arrives, the OV_LinkDown_NodeDown correlator extracts thenode ID from the OV_APA_NODE_DOWN event.
4. A set is considered complete when at least one OV_Link_Down eventand one OV_APA_NODE_DOWN event is received from the same nodewithin a specified window period.
5. When a set is complete, all OV_Link_Down events received during aspecified window period with the same node ID as theOV_APA_NODE_DOWN event are correlated under theOV_APA_NODE_DOWN alarm.
6. In addition, the corresponding LinkDown events are removed fromthe NNM alarm browser.
Chapter 7 209
APA and Event ReductionOV_PollerLinkDown Namespace
Configurable Parameters
The only configurable parameter, by default, is:
• Window Period
For instructions on how to modify this parameter, see “SettingParameters” on page 230. Note that the OV_LinkDown_NodeDowncorrelator is contained within the OV_PollerLinkDown namespace.
LinkDown Events and APA Connection Status Alarms
Listens for LinkDown events and OV_APA_CONNECTION_DOWN orOV_APA_CONNECTION_UNREACHABLE alarms. LinkDown events receivedwithin M minutes from the same source as the APA connection statusalarm are suppressed and nested beneath the APA connection statusalarm (default M=10 minutes).
Behavior
When APA is enabled, the OV_LinkDown_ConnDown correlator works withthe OV_Link_Down correlator in the following way:
1. The OV_Link_Down correlator listens for LinkDown events. When aLinkDown events arrives, the OV_Link_Down correlator generates anew, enhanced alarm, OV_Link_Down.
2. The OV_LinkDown_NodeDown correlator listens for OV_Link_Downalarms and extracts the associated node and interface IDs from thesealarms.
3. The OV_LinkDown_ConnDown correlator waits for anOV_APA_CONNECTION_DOWN or OV_APA_CONNECTION_UNREACHABLEalarm to arrive. When an OV_APA_CONNECTION_DOWN orOV_APA_CONNECTION_UNREACHABLE alarm arrives, theOV_LinkDown_ConnDown correlator extracts the node and interfaceIDs from the OV_APA_CONNECTION_DOWN orOV_APA_CONNECTION_UNREACHABLE alarm.
4. A set is considered complete when at least one OV_Link_Down alarmand one OV_APA_CONNECTION_DOWN orOV_APA_CONNECTION_UNREACHABLE alarm is received from the samesource within a specified window period.
Chapter 7210
APA and Event ReductionOV_PollerLinkDown Namespace
5. When a set is complete, all OV_Link_Down alarms received during aspecified window period with the same node and interface IDs as theOV_APA_CONNECTION_DOWN alarm are correlated under theOV_APA_CONNECTION_DOWN alarm.
6. In addition, the corresponding LinkDown events are removed fromthe NNM alarm browser.
Configurable Parameters
The only configurable parameter, by default, is:
• Window Period
For instructions on how to modify this parameter, see “SettingParameters” on page 230. Note that the OV_LinkDown_ConnDowncorrelator is contained within the OV_PollerLinkDown namespace.
Chapter 7 211
APA and Event ReductionOV_CiscoBoard Namespace
OV_CiscoBoard NamespaceThe OV_CiscoBoard namespace contains a set of correlators thatdetermine if LinkDown events and syslog Link Down and Line ProtocolDown messages are secondary events to Board Down (or ModuleDown)events or syslog Board Down messages. Secondary events are correlatedunder the root cause event identifying the board (or module) that failed.
LinkDown and Syslog Down Events with Board DownEvents
Correlates secondary board failure events, such as LinkDown and syslogLink Down, with Board Down events.
Behavior
When a board (or module) fails on a Cisco device, several secondaryevents can be generated in addition to the Board Down event. It isdesirable to see the root cause Board Down event identifying the boardthat failed. The other secondary events should be correlated beneath thethe root cause board failure alarm. The following correlators help achievethis:
• The OV_Link_Down and OV_Link_Down2 correlators listen forLinkDown events, and stores the events based on the board (ormodule) ID identified in the event.
• The OV_Syslog_LinkDown correlator listens for syslog Link Downevents and syslog Line Protocol Down events, and stores the eventsbased on the board (or module) ID identified in the event.
• The OV_Board_Down correlator listens for Board Down (orModuleDown) events and stores the events based on the board (ormodule) ID identified in the event. It then retrieves all secondaryevents with the same board ID and nests them beneath the BoardDown event in the alarm browser.
The following steps demonstrate in more detail how the correlatorsfunction:
1. A board (or module) fails on a Cisco device.
Chapter 7212
APA and Event ReductionOV_CiscoBoard Namespace
2. A LinkDown event, syslog Link Down event, or syslog Line ProtocolDown event is generated and forwarded to NNM.
3. The board ID is extracted from the event and stored in a table for 1minute.
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 IDsstored in the table.
6. All matching events are nested under the Board Down event in thealarm browser.
7. The table cache is cleared.
The suppressed alarms can be viewed from the alarm browser bydouble-clicking the root cause Board Down alarm.
Configurable Parameters
No parameters for these correlators are configurable.
LinkDown and Syslog Down Events with SyslogBoard Down Events
Correlates secondary board failure events, such as LinkDown and syslogLink Down, with syslog Board Down events.
Behavior
When a board (or module) fails on a Cisco device, several secondaryevents can be generated in addition to the syslog Board Down event. It isdesirable to see the root cause syslog Board Down event identifying theboard that failed. The other secondary events should be correlatedbeneath the root cause board failure alarm. The following correlatorshelp 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 inthe event.
• The OV_Syslog_LinkDown correlator listens for syslog Link Downevents and syslog Line Protocol Down events, and stores the eventsbased on the board (or module) ID identified in the event.
Chapter 7 213
APA and Event ReductionOV_CiscoBoard Namespace
• The OV_Board_Down_Syslog correlator listens for syslog Board Down(or ModuleDown) events and stores the events based on the board (ormodule) ID identified in the event. It then retrieves all secondaryevents with the same board ID and nests them beneath the BoardDown event in the alarm browser.
The following steps demonstrate in more detail how the correlatorsfunction:
1. A board (or module) fails on a Cisco device.
2. A LinkDown event, syslog Link Down event, or syslog Line ProtocolDown event is generated and forwarded to NNM.
3. The board ID is extracted from the event and stored in a table for 1minute.
4. A syslog Board Down event is generated identifying the board thatfailed.
5. The board ID of the syslog Board Down event is compared to theboard and node object IDs stored in the table.
6. All matching events are nested under the syslog Board Down event inthe alarm browser.
7. The table cache is cleared.
The suppressed alarms can be viewed from the alarm browser bydouble-clicking the root cause syslog Board Down alarm.
Configurable Parameters
No parameters for these correlators are configurable.
Board Down and Syslog Board Down EventsCorrelator
Correlates Board Down events and syslog Board Down events. The first toarrive is posted to the alarm browser; the other alarms are nestedbeneath the first.
Chapter 7214
APA and Event ReductionOV_CiscoBoard Namespace
Behavior
The Board Down (or ModuleDown) event and the syslog Board Down (orModuleDown) event are essentially duplicate events. Thus, it is desirableto post the first of these events to the alarm browser, and correlate theother events beneath the first. The OV_Board_Trap_SyslogCorrcorrelator helps achieve this.
The OV_Board_Trap_SyslogCorr correlator retrieves the board ID andnode ID values from Board Down and syslog Board Down events stored inthe OV_Board_Down and OV_Board_Down_Syslog correlators. When amatch occurs, the first event to arrive becomes the top-level alarm andthe other event is correlated beneath the top-level alarm.
Configurable Parameters
No parameters for this correlator is configurable.
Chapter 7 215
APA and Event ReductionOV_PollerBoardDown Namespace
OV_PollerBoardDown NamespaceThe OV_PollerBoardDown namespace contains a set of correlators thatdetermine if Board Down events or syslog Board Down messages shouldbe nested under the root cause APA Board Down alarm. Whenappropriate, the Board Down events are correlated under the APA BoardDown 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 theroot cause APA Board Down alarm.
Behavior
When a board (or module) fails on a Cisco device, the board failure isdetected by APA and an APA Board Down alarm is generated. BoardDown events are likely to be generated by the Cisco device too. It isdesirable to see the APA root cause alarm identifying the board thatfailed with the other Board Down events correlated beneath the rootcause alarm. The following correlators help achieve this:
• The OV_Board_Down correlator listens for Board Down (orModuleDown) events and stores the events based on the board (ormodule) ID identified in the event and the node object ID extractedfrom the topology database.
• The OV_APA_BoardDown correlator listens for APA Board Downalarms. It then retrieves all Board Down events with the same nodeID and board ID and nests them beneath the APA Board Downalarm in the alarm browser.
The following steps demonstrate in more detail how the correlatorsfunction:
1. A board (or module) fails on a Cisco device.
2. A Board Down event is generated and forwarded to NNM.
3. The board ID is extracted from the event and the node ID isextracted from the topology database. The information is stored in atable for 330 seconds.
Chapter 7216
APA and Event ReductionOV_PollerBoardDown Namespace
4. An APA Board Down alarm is generated identifying the board thatfailed and posted to the Status Alarm category of the NNM alarmbrowser.
5. The node object ID and board ID of the APA Board Down alarm iscompared to the board and node object IDs stored in the table.
6. All matching events are nested under the APA Board Down alarm inthe Status Alarms Browser.
7. The table cache is cleared.
The suppressed alarms can be viewed from the alarm browser bydouble-clicking the root cause APA Board Down alarm.
Configurable Parameters
No parameters for these correlators are configurable.
Syslog Board Down Events with APA Board FailureAlarms
Correlates syslog Board Down events with the root cause APA BoardDown alarm.
Behavior
When a board (or module) fails on a Cisco device, the board failure isdetected by APA and an APA Board Down alarm is generated. SyslogBoard Down events are likely to be generated by the Cisco device too. It isdesirable to see the APA root cause alarm identifying the board thatfailed with the other syslog Board Down events correlated beneath theroot cause alarm. The following correlators help achieve this:
• The OV_Syslog_BoardDown correlator listens for syslog Board Downevents, and stores the events based on the board (or module) IDidentified in the event and the node object ID extracted from thetopology database.
• The OV_APA_BoardDown correlator listens for APA Board Downalarms. It then retrieves all syslog Board Down events with the samenode ID and board ID and nests them beneath the APA Board Downalarm in the alarm browser.
The following steps demonstrate in more detail how the correlatorsfunction:
Chapter 7 217
APA and Event ReductionOV_PollerBoardDown Namespace
1. A board (or module) fails on a Cisco device.
2. A Board Down event is generated and forwarded to NNM.
3. The board ID is extracted from the event and the node ID isextracted from the topology database. The information is stored in atable for 330 seconds.
4. An APA Board Down alarm is generated identifying the board thatfailed and posted to the Status Alarm category of the NNM alarmbrowser.
5. The node object ID and board ID of the APA Board Down alarm iscompared to the board and node object IDs stored in the table.
6. All matching events are nested beneath the APA Board Down alarmin the Status Alarms Browser.
7. The table cache is cleared.
The suppressed alarms can be viewed from the alarm browser bydouble-clicking the root cause APA Board Down alarm.
Configurable Parameters
No parameters for these correlators are configurable.
Chapter 7218
APA and Event ReductionOV_PollerTrigger Namespace
OV_PollerTrigger NamespaceThe OV_PollerTrigger namespace contain a set of correlators thattrigger an immediate APA poll and analysis of a network entity (of typenode, interface, board, or HSRP group). When certain types of traps orsyslog messages arrive, these correlators generate the appropriate APApoll trigger request on the network entity. Depending on the type ofevent, the correlators may issue a status poll request, a configurationpoll 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 APApoll and analysis should be scheduled immediately instead of waiting forthe next APA poll cycle. These correlators listen for events that are notmonitored by APA and generate the appropriate poll trigger request.
There are three types of network entities that can be specified in the polltrigger request: node, interface, and board. This informs APA as to whichtype 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 isup.
• DOWN - A poll request to determine if the status of a network entityis down.
• CONFIGURATION - A poll request to determine the status of anetwork entity. For example, a configuration poll request might bemade to determine if a node has been rebooted.
• FORCE - A poll request to determine the status of a network deviceregardless of current status.
The following steps demonstrate in more detail how the correlatorsfunction.
Chapter 7 219
APA and Event ReductionOV_PollerTrigger Namespace
1. A network device forwards an event to the NNM managementstation (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, whichissues a poll trigger request. The type of poll trigger request to beissued for that event is listed in Table 7-1.
The APA Demand Analysis event is generated only when thefollowing two criteria are met:
• No other event, such as LinkDown or LinkUp, has been sentdirectly to poller.
• No other APA Demand Analysis event for that event source andpoll 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 theother APA correlators. The events may be correlated under the firstevent of its kind, or correlated under the APA alarm that isgenerated as a result of the triggered APA polling.
Table 7-1 Events Being Monitored by the APA Poll Trigger Correlators
Events Type of PollIssue
TriggertoAPA
Object Type forTrigger Event
LinkDown DOWN No Interface
LinkUp UP No Interface
%LINK-3-UPDOWN: Interface[chars] changed state to down
DOWN Yes Interface
%LINK-3-UPDOWN: Interface[chars] changed state to up
UP Yes Interface
%LINEPROTO-5-UPDOWN :Line protocol on Interface [chars],changed state to down
DOWN Yes Interface
Chapter 7220
APA and Event ReductionOV_PollerTrigger Namespace
%LINEPROTO-5-UPDOWN :Line protocol on Interface [chars],changed state to
UP Yes Interface
Board (Module) Down DOWN No Board
Board (Module) Up UP No Board
%SNMP-5-MODULETRAP:Module [dec] down Trap
DOWN Yes Board
%SNMP-5-MODULETRAP:Module [dec] up Trap
UP Yes Board
%SYS-5-MOD_NORESPONSE:Module [dec] failed to respond
DOWN Yes Board
%SYS-5-MOD_OK: Module [dec]is online
UP Yes Board
%SYS-5-MOD_REMOVE: Module[dec] has been removed
CONFIG Yes Board
%SYS-5-MOD_INSERT: Module[dec] has been removed
CONFIG Yes Board
%SYS-5-MOD_RESET: Module[dec] reset from [chars]
CONFIG Yes Board
%SYS-3-MOD_FAIL: Module[dec] failed to come online
DOWN Yes Board
%SYS-3-MOD_FAILREASON:Module [dec] configurationmismatch
DOWN Yes Board
%SYS-3-MOD_CFGMISMATCH1: Module [dec] configurationmismatch [chars]
CONFIG Yes Board
Table 7-1 Events Being Monitored by the APA Poll Trigger Correlators
Events Type of PollIssue
TriggertoAPA
Object Type forTrigger Event
Chapter 7 221
APA and Event ReductionOV_PollerTrigger Namespace
%SYS-3-MOD_CFGMISMATCH2: *Config: [chars}
CONFIG Yes Board
%SYS-3-MOD_CFGMISMATCH3: *Actual: [chars]
CONFIG Yes Board
%SYS-3-MOD_CFGMISMATCH4: Insert config type module or do a‘clear config [dec]’
CONFIG Yes Board
Cold Start CONFIG No Node
Warm Start CONFIG No Node
%SYS-5-RELOAD: Reloadrequested
None No Node
%SYS-5-RESTART: Systemrestarted
CONFIG Yes Node
%OSPF-5-ADJCHG: Process[dec], Nbr [int] on [chars] from[chars] to DOWN
FORCE Yes Node
%OSPF-5-ADJCHG: Process[dec], Nbr [int] on [chars] from[chars] to FULL
FORCE Yes Node
%STANDBY-6-STATECHANGE:Standby: [dec]: [chars] stateActive -> Speak
FORCE Yes HSRP Group
%STANDBY-6-STATECHANGE:Standby: [dec]: [chars] stateSpeak -> Standby
FORCE Yes HSRP Group
%STANDBY-6-STATECHANGE:Standby: [dec]: [chars] stateStandby -> Active
FORCE Yes HSRP Group
Table 7-1 Events Being Monitored by the APA Poll Trigger Correlators
Events Type of PollIssue
TriggertoAPA
Object Type forTrigger Event
Chapter 7222
APA and Event ReductionOV_PollerTrigger Namespace
Configurable Parameters
No parameters for these correlators are configurable.
%STANDBY-6-STATECHANGE:Standby: [dec]: [chars] stateStandby -> Init
FORCE Yes HSRP Group
%PAGP-5-PORTTOSPT: Port[dec]/[dec] joined bridge port[dec]/[chars]
FORCE Yes Interface
%PAGP-5-PORTFROMSPT: Port[dec]/[dec] left bridge port[dec]/[chars]
FORCE Yes Interface
Table 7-1 Events Being Monitored by the APA Poll Trigger Correlators
Events Type of PollIssue
TriggertoAPA
Object Type forTrigger Event
Chapter 7 223
APA and Event ReductionOV_PollerTriggerCorr Namespace
OV_PollerTriggerCorr NamespaceThe OV_PollerTriggerCorr namespace contains a set of correlatorsthat correlate duplicate poll trigger events not already being correlatedby the other APA correlators. Secondary events are correlated under thefirst event to arrive or under the APA alarm that is generated as a resultof the poll request.
OSPF Adjacency Change Events with APA Root CauseAlarms
Correlates OSPF Adjacency Change events with APA root cause alarms.
Behavior
When APA is enabled, the OV_OSPF_AdjacencyChange correlator workswith the OV_OSPF_APA correlator in the following way:
1. The OV_OSPF_AdjacencyChange correlator listens for OSPFAdjacency Change events.
2. The node object ID is extracted from topology database and stored intable for 3 minutes.
3. An APA root cause alarm of the following type is generated andposted 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 objectIDs of the OSPF Adjacency Change events.
5. All matching OSPF Adjacency Change events are nested beneaththe APA alarm in the Status Alarm Browser.
6. The table cache is cleared.
Chapter 7224
APA and Event ReductionOV_PollerTriggerCorr Namespace
The suppressed OSPF Adjacency Change events can be viewed from theStatus Alarms Browser by double-clicking the root cause APA alarm.
Configurable Parameters
No parameters for these correlators are configurable.
HSRP State Change Events with HSRP Root CauseAlarms
Correlates HSRP State Change events with APA HSRP root causealarms.
Behavior
When APA is enabled, the OV_HSRP_StateChange correlator works withthe OV_HSRP_APA correlator in the following way:
1. The OV_HSRP_StateChange correlator listens for HSRP StateChange events.
2. The node object ID is extracted from topology database and stored intable for 5 minutes.
3. An APA root cause alarm of the type OV_HSRP is generated andposted to the Status Alarms category of the NNM alarm browser.
4. The node object ID of the APA alarm is compared to the node objectIDs of the HSRP State Change events.
5. All matching HSRP State Change events are nested beneath theAPA alarm in the Status Alarm Browser.
6. The table cache is cleared.
The suppressed HSRP State Change events can be viewed from theStatus Alarms Browser by double-clicking the root cause APA alarm.
Configurable Parameters
No parameters for these correlators are configurable.
Restart-Type Events with APA Node Status Alarms
Correlates Cold Start/Warm Start events and syslog RELOAD/RESTARTevents with APA Node status alarms.
Chapter 7 225
APA and Event ReductionOV_PollerTriggerCorr Namespace
Behavior
When APA is enabled, the OV_NodeRestart_Syslog andOV_Node_Restart_Trap correlators work with the OV_NodeRestart_APAcorrelator in the following way:
1. The OV_NodeRestart_Syslog and OV_Node_Restart_Trapcorrelators 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 extractedfrom topology database and stored in table for 3 minutes.
3. An APA root cause alarm of the type OV_APA_NODE_UP orOV_APA_NODE_RENUMBERING is generated and posted to the StatusAlarms category of the NNM alarm browser.
4. The node object ID of the APA alarm is compared to the node objectIDs of the restart-type events stored in the table.
5. All matching events are nested beneath the APA alarm in the StatusAlarm Browser.
6. The table cache is cleared.
The suppressed events can be viewed from the Status Alarms Browser bydouble-clicking the root cause APA alarm.
Configurable Parameters
No parameters for these correlators are configurable.
Chapter 7226
APA and Event ReductionOV_PollerPortAgg Namespace
OV_PollerPortAgg NamespaceThe OV_PollerPortAgg namespace contains a set of correlators thatdetermine if LinkDown events and syslog Down events as well as syslogport aggregation events are secondary events to APA port aggregationstatus alarms. Secondary events are correlated under the APA root causealarm.
LinkDown Events and Syslog Down Events with APAAggregated Port Alarms
Correlates LinkDown events and syslog Link Down and Line ProtocolDown events under the root cause aggregated port alarm generated byAPA.
Behavior
It is desirable to see the root cause APA alarm in the alarm browser withaggregated port failure events nested under the APA alarm. TheOV_Link_Down, OV_Syslog_LinkDown, and OV_APA_AggregatedPortcorrelators help achieve this.
• The OV_Link_Down correlator listens for LinkDown events and storesthe events based on the node object ID extracted from the topologydatabase.
• The OV_Syslog_LinkDown correlator listens for syslog Link Downand Line Protocol Down events and stores the events based on thenode object ID extracted from the topology database.
• The OV_APA_AggregatedPort correlator listens for APA AggregatedPort alarms. It then retrieves all LinkDown events and syslog Downevents from the correlators that have the same node object ID andnests them beneath the APA Aggregated Port alarm.
The following steps demonstrate in more detail how the correlatorsfunction:
1. An aggregated port fails or its performance is degraded because of anunderlying interface failure on a Cisco device.
2. A LinkDown event, a syslog Link Down event, or a syslog LineProtocol Down event is generated and forwarded to NNM.
Chapter 7 227
APA and Event ReductionOV_PollerPortAgg Namespace
3. The node object ID is extracted from the event and stored in a tablefor 1 minute.
4. An APA Aggregated Port alarm is generated and posted to the StatusAlarm category of the NNM alarm browser.
5. The node object ID of the APA Aggregated Port alarm is compared tothe node object IDs stored in the table.
6. All matching events are nested under the APA Aggregated Portalarm in the Status Alarm Browser.
7. The table cache is cleared.
The suppressed events can be viewed from the Status Alarms Browser bydouble-clicking the APA Aggregrated Port alarm.
Configurable Parameters
No parameters for these correlators are configurable.
Syslog Port Aggregation Events with APA AggregatedPort Alarms
Correlates syslog aggregated port events (PAGP messages) under theroot cause alarm generated by APA.
Behavior
It is desirable to see the root cause APA alarm in the alarm browser withsyslog aggregated port failure events nested under the APA alarm. TheOV_Port_Aggregation and OV_APA_AggregatedPort correlators helpachieve this.
• The OV_Port_Aggregation correlator listens for syslog portaggregation events (PAGP messages) and stores the events based onthe node object ID extracted from the topology database.
• The OV_APA_AggregatedPort correlator listens for APA AggregatedPort alarms. It then retrieves all syslog port aggregation events fromthe OV_Port_Aggregation correlator that have the same node objectID and nests them beneath the APA Aggregated Port alarm.
The following steps demonstrate in more detail how the correlatorsfunction:
Chapter 7228
APA and Event ReductionOV_PollerPortAgg Namespace
1. An aggregated port fails or its performance is degraded because of anunderlying interface failure on a Cisco device.
2. A syslog PAGP_JoinedBridgePort event or PAGP_LeftBridgePortevent is generated and forwarded to NNM.
3. The node object ID is extracted from the event and stored in a tablefor 330 seconds (5.5 minutes).
4. An APA Aggregated Port alarm is generated and posted to the StatusAlarm category of the NNM alarm browser.
5. The node object ID of the APA Aggregated Port alarm is compared tothe node object IDs stored in the table.
6. All matching events are nested under the APA Aggregated Portalarm in the Status Alarm Browser.
7. The table cache is cleared.
The suppressed events can be viewed from the Status Alarms Browser bydouble-clicking the APA Aggregated Port alarm.
Configurable Parameters
No parameters for these correlators are configurable.
Chapter 7 229
APA and Event ReductionSetting Parameters
Setting ParametersComplete the following steps if you want to review parameter definitionsor modify parameters contained within a Correlation Composercorrelator.
TIP There are several ways to access the event correlation features. For moreinformation, from any submap, select Tools:HP OpenView Launcher.Select the [?] tab. Click Tasks, Event Correlation Management. Readthe information under Accessing the Event Correlation ConfigurationWindows.
1. From any submap, select Options:Event Configuration. Thislaunches the Event Configuration window.
2. From NNM’s Event Configuration window, select Edit:EventCorrelation. This brings up the ECS Configuration window.
3. From the ECS Configurationwindow, 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 appropriatenamespace from the NameSpace table. Its correlators are displayedin 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. Ifyou need to modify values of other parameters, open CorrelationComposer in developer mode. See HP OpenView CorrelationComposer's Guide for more information about Correlation Composerin developer mode.
7. Click the Definition tab to access the configurable parametersetting. Click [Help] for information about each field.
8. After making the desired change, click [OK] and close the correlatorconfiguration window and return to the Correlation Composermain window.
Chapter 7230
APA and Event ReductionSetting Parameters
9. Save your change by clicking File:Save. This updates the correlatorfact store file associated with the namespace.
10. To activate your change, click File:Close and then clickCorrelations:Deploy.
11. Exit the Correlation Composer main window.
Chapter 7 231
APA and Event ReductionDisabling APA Correlators and Correlator Groups
Disabling APA Correlators and CorrelatorGroupsFor testing purposes or performance reasons, you may want to disable acorrelator or group of correlators. For example, if Syslog Integration isnot enabled, you may want to disable individual syslog-specificcorrelators. Moreover, you might find that disabling one correlatorcauses other correlators in its group not to be useful anymore, so youmay want to disable the entire group of correlators.
Note that all of the APA correlators are distinct; meaning they worktogether to provide a set of functionality, but may be turned on or offindependent 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 Composercorrelator.
TIP There are several ways to access the event correlation features. For moreinformation, from any submap, select Tools:HP OpenView Launcher.Select the [?] tab. Click Tasks, Event Correlation Management. Readthe information under Accessing the Event Correlation ConfigurationWindows.
1. From any submap, select Options:Event Configuration. Thislaunches the Event Configuration window.
2. From NNM’s Event Configuration window, select Edit:EventCorrelation. This brings up the ECS Configuration window.
3. From the ECS Configurationwindow, select the ‘default’ stream.Then, highlight Composer in the correlation table and select Modify.The Correlation Composer window appears in your web browser.
Chapter 7232
APA and Event ReductionDisabling APA Correlators and Correlator Groups
4. In the Correlation Composer window, select the appropriatenamespace from the NameSpace table. Its correlators are displayedin the Correlator Store.
5. To disable a correlator, click within the box in the Enable column forthat correlator in the Correlator Store.
6. Save your change by clicking File:Save. This updates the correlatorfactstore file associated with the namespace.
7. To activate your change, click File:Close and then clickCorrelations: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 thedefinitions of the correlators. The association of the factstore file with anamespace 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 thenamespace/factstore file pair from the NameSpace.conf file as detailedbelow.
1. Open the Correlation Composer namespace file, NameSpace.conf.
2. Identify the namespace or the factstore file containing the group ofcorrelators that you want to disable. For example, the correlatorsthat trigger APA poll requests are defined in the PollerTrigger.fsfactstore file. Its associated namespace is PollerTrigger.
3. Remove the entry in NameSpace.conf that associates the factstorefile with its namespace. For example, to remove the APA Poll Triggercorrelators, delete the line: PollerTrigger=PollerTrigger.fs
4. Save the NameSpace.conf file.
5. Deploy the correlations to activate your changes.
Chapter 7 233
APA and Event ReductionDisabling APA Correlators and Correlator Groups
a. From any submap, select Options:Event Configuration. Thislaunches the Event Configuration window.
b. From NNM’s Event Configurationwindow, select Edit:EventCorrelation. This brings up the ECS Configuration window.
c. From the ECS Configuration window, select the ‘default’stream. Then, highlight Composer in the correlation table andselect Modify. The Correlation Composer window appears inyour web browser.
d. Make sure all files are closed and click Correlations:Deploy.
e. Exit the Correlation Composer main window.
Chapter 7234
APA and Event ReductionTroubleshooting
TroubleshootingFor troubleshooting information about the Correlation Composer, see thefollowing references:
• Access the following pdf format manual from the NNM main window,select Help:Documentation:
— HP OpenView Correlation Composer's Guide
Chapter 7 235
APA and Event ReductionTroubleshooting
Chapter 7236
8 The Advanced Routing SmartPlug-in
Chapter 8 237
The Advanced Routing Smart Plug-inWhat the Advanced Routing Smart Plug-in Discovers
What the Advanced Routing Smart Plug-inDiscoversThe Advanced Routing SPI (Smart Plug-in) enables Extended Topologyto discover information about HSRP groups, OSPF areas, and devicesthat support IPv6. You must purchase and install a license for theAdvanced Routing SPI to use this functionality. To review additionalnetwork SPIs, point your browser to http://openview.hp.com and followthe links to OpenView products.
Discovering HSRP Information
The Advanced Routing SPI enables Extended Topology to discover anddisplay HSRP information from managed devices that support the HSRPprotocol.
While HSRP discovery is automatic, there are important preliminarysteps you need to take to assure correct HSRP discovery and monitoring.If you want to discover and monitor HSRP groups, see “Running HSRPDiscovery” on page 257 for details.
The Active Problem Analyzer polls HSRP routers and reports HSRPgroup status information. See“Understanding HSRP View StatusInformation” on page 260 for more information.
Once HSRP discovery and monitoring is functional, see “Using the HSRPView to Diagnose Network Problems” on page 263 or the HP OpenViewweb online help for information on using this feature.
Discovering OSPF Information
The Advanced Routing SPI enables Extended Topology to discover anddisplay OSPF information. OSPF discovery is a separate process fromthe Extended Topology discovery. You run OSPF discovery by using amanual discovery procedure. See “Running OSPF Discovery” onpage 252 for more information about OSPF discovery.
Another product, the HP OpenView Route Analytics ManagementSystem (RAMS), together with the NNM/RAMS Integration Module,represents a superior solution to OSPF management. By activelyparticipating in the network protocols, RAMS provides near real-time
Chapter 8238
The Advanced Routing Smart Plug-inWhat the Advanced Routing Smart Plug-in Discovers
routing data across multiple protocols. Coupled with NNM AdvancedEdition, it greatly enhances the root-cause analysis and visualization ofyour OSPF routing fabric.
Discovering IPv6 Information
The Advanced Routing SPI enables Extended Topology to discover anddisplay IPv6 information. When you run IPv6 discovery, ExtendedTopology discovers global, site-local, and link-local addresses. Themanagement station and all routers must be dual-stacked for IPv6discovery to function properly.
To prepare the Advanced Routing SPI for IPv6 discovery, you must runthe 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
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
Running IPv6 DiscoveryBefore starting your IPv6 discovery, you need add some information tothree 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 yourneeds. Each file contains configuration examples and instructionsshowing how to add information. Use the following procedure tocomplete your IPv6 discovery:
1. Modify the IPv6Seed.conf file.
The Advanced Routing SPI uses the IPv6Seed.conf file to seed yourIPv6 discovery. For best results, enter the addresses of all of therouters and end nodes you want to discover into this file. To enterthese addresses, follow the instructions included within theIPv6Seed.conf file.
2. This step is not mandatory. The Advanced Routing SPI reads routingtables from routers and can discover devices beyond the nodesspecified in the IPv6Seed.conf file. If you want to limit IPv6discovery to the nodes you add to this file, edit the IPv6.conf file andfollow the instructions contained in the file.
Chapter 8240
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
3. Modify the IPv6Prefix.conf file.
IPv6 prefix groups are similar to subnets in IPv4. TheIPv6Prefix.conf file is used to give a user-friendly name to yourprefix groups once they are discovered.
4. This step is not mandatory. The Advanced Routing SPI allows you tolist prefix groups and IPv6 addresses that you either want discoveredor want excluded from discovery. To enter these addresses or prefixgroups, follow the instructions included within the IPv6Scope.conffile.
5. This step is not mandatory. You can modify the IPv6Polling.conffile if you need to change the polling frequency.
The IPv6Polling.conf file is used to modify the polling frequency ofnodes.
6. If you are installing Extended Topology for the first time, you need toexecute 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 ExtendedTopology Discovery” on page 23 for more information about thesetupExtTopo.ovpl script.
7. If you v the setupExtTopo.ovpl script prior to configuring your IPv6discovery, you need to execute, as Administrator or root, thefollowing 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 nameresolution. You can achieve name resolution by using either a DNSserver or hosts files. Make sure all of your IPv6 addresses resolveproperly before proceeding.
Execute the IPv6NameByAddr command as follows to check reverse nameresolution:
Chapter 8 241
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
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 informationabout 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 SPIdiscovers IPv6 nodes beyond the seed file entries. Extra IPv6 nodeswill show up if they are found in the router’s tables.
• Some nodes are missing from the map: Make sure these nodes areentered 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 willdiscover these nodes. Make sure you enter only valid nodes in theIPv6Seed.conf file.
• Extended Topology shows a node’s status as being down when youknow the node is up: Extended Topology relies on the AdvancedAdvanced Routing SPI’s IPv6 ping for all its status. Make sure youcan IPv6 ping all of the node’s IPv6 addresses from the managementstation.
• The map shows your end nodes labeled with IPv6 Addresses ratherthan names: Make sure that both forward and reverse DNS areworking for the node from the management station.
• Your routers are showing up as end nodes instead of routers: Makesure this is a supported router with IPv6 MIBs loaded. Forinformation about how to find out which IPv6 devices the AdvancedRouting SPI supports, see “Obtaining Supported Device Information”on page 276. Also make sure you have SNMP access properlyconfigured.
• Your map shows prefix groups connected to the router but no endnodes in the prefix groups. There are several possible solutions listedbelow:
Chapter 8242
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
— You may have the End Nodes check box deselected in the view.
— The router may be the only node in the prefix group. This iscommon for routers. Many times routers have prefix groupsconfigured 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 canaccess your router via SNMP from the management station. Also,make sure the IPv6 routers you are discovering support the IPv6MIBs.
• Your topology looks incorrect on the map. There are several possiblesolutions listed below:
— Reload the page. If you bring up the page while a lot of statusevents are being generated, the topology shows up incorrect.
— Make sure the prefix length is correct for the addresses in theseed file.
Properly Displaying Routers not Supporting IPv6MIBs
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 routerproperly, take the following steps:
1. Ensure that all IPv6 interface addresses are registered on your DNSserver with the same name.
2. Ensure that at least one IPv4 interface of the router is alsoregistered on your DNS server under the same name.
3. Ensure that you have configured the SNMP community strings inNNM for the IPv4 interface of the router.
4. Ensure that all IPv6 addresses and prefix lengths for the router arelisted in the following file without specifying an optional name.
• Windows: %OV_CONF%\nnmet\IPv6Seed.conf
Chapter 8 243
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
• UNIX: $OV_CONF/nnmet/IPv6Seed.conf
5. Identify all end nodes located beyond the router that you wish tomanage and enter their addresses in the IPv6Seed.conf file sincethese end nodes won’t get discovered automatically. Do not enter thelink-local addresses of these nodes.
Properly Displaying IPv6 Nodes with MultipleAddresses
If you configure a node with more than one IPv6 address you should listall 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 onyour DNS server with the same name.
2. Make sure that all IPv6 addresses for this node are listed in the seedfile without specifying an optional name.
Viewing IPv6 Information
You can access an index of all the NNM and Extended Topology views bypointing your web browser to the following URL:
• http://hostname/:7510
From this index you can access the IPv6 Network View and the IPv6information.
NOTE There are several other ways to view IPv6 Information. See “AccessingDynamic Views” on page 16 for additional information.
IPv6 Network View
If you select the IPv6 Network View from Home Base, the AdvancedRouting SPI displays a global map showing all discovered IPv6 globalprefix groups and the nodes logically connected to each prefix group.
Chapter 8244
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
The IPv6 Network View displays nodes having Global addresses, alsocalled aggregatable global unicast addresses. These addresses refer toIPv6 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 namesproperly, you will see nodes with names rather than addresses. If DNS isnot resolving names properly, your views will contain one of the node’sIPv6 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 detailsabout that node. Node status is updated dynamically. See“Understanding IPv6 Status Information” on page 248 for moreinformation on how the Advanced Routing SPI determines node status.
The default setting for Scope has both the Global option button and theInclude End Nodes check box selected. If you want to restrict the viewto 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 radiobutton and select [Refresh]. For more information see “IPv6 Site-LocalNetwork View” on page 248.
If you use IPv4 compatible addresses, be aware that IPv4 compatiblestatus is not shown in the table. You can select any of the interface linksto get all the related status information for any of the interfaces.
Prefix Groups Along with routers and end-nodes, the AdvancedRouting SPI allows Extended Topology to display prefix groups. Prefixgroups are similar to subnets in IPv4. All nodes that have addressesbelonging to a specific prefix group are shown as being connected to thatprefix group’s icon.
The Advanced Routing SPI allows you to name your prefix groups in thefollowing 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 onconfiguring your prefix group names.
Chapter 8 245
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
NOTE Link-local addresses are not assigned a prefix group and will not show upin the map unless their parent nodes also have a global or site-localaddress. The Advanced Routing SPI never polls link-local addresses forstatus.
IPv6 nodes can have more than one address per interface. In IPv6 views,connection lines between nodes and prefix groups do not alwaysrepresent a one-to-one mapping to interfaces on a node. A singleinterface can have multiple addresses which may be in two differentprefix groups.
Refer to Table 8-1 on page 247 when reviewing the following possibleexamples:
• If a node has one interface and that interface has one global address,the Advanced Routing SPI displays only one line connecting the nodeto one prefix group.
• If a node has one interface and has two global addresses within thesame prefix group, the Advanced Routing SPI displays only one lineconnecting the node to one prefix group.
• If a node has one interface and has two global addresses with twodifferent prefixes, the Advanced Routing SPI displays two linesconnecting the node to two different prefix groups.
• If a node has two interfaces and a total of four global addressesbelonging to three different prefix groups, the Advanced Routing SPIdisplays three lines connecting the node to three different prefixgroups.
Chapter 8246
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
D
A nodinterintergloba
A nodinterinterglobawithiprefix
A nodinterinterglobawith prefix
A nodintertotaladdrbelondiffer
Table 8-1 Prefix Group Scenarios
escription NodeCount
Inter-face
Count
GlobalAddressCount
PrefixCount Expected Result View
e has oneface and thatface has onel address.
1 1 1 1 The node has oneline going to theprefix groupsymbol.
e has oneface and theface has twol addressesn the same.
1 1 2 1 The node has oneline going to thecorrespondingprefix groupsymbol.
e has oneface and theface has twol addressesdifferentes.
1 1 2 2 The node has twolines going to thetwo prefix groupsymbols.
e has twofaces and a of four globalessesging to threeent prefixes.
1 2 4 3 The node hasthree lines goingto three prefixgroup symbols.
Node
PrefixGroup
Node
PrefixGroup
Node
PrefixPrefix
Group
Group
Node
Prefix
PrefixGroup
PrefixGroup
Group
Chapter 8 247
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
The status of a prefix group is compounded from the status of theaddresses belonging to the prefix group. For example, suppose a prefixgroup icon is colored blue. This means that there is an address that is notresponding to IPv6 pings within that prefix group. See “UnderstandingIPv6 Status Information” on page 248 for more information onunderstanding IPv6 node status.
IPv6 Site-Local Network View From Home Base, if you selectthe IPv6 Network View, then select a Site Local Network View, theAdvanced Routing SPI displays a site-local map, showing all discoveredIPv6 site-local prefix groups and the nodes logically connected to eachprefix group.
If you double-click on a site-local prefix group, you can view the nodescontained within that site-local prefix group. You can double-click on aprefix group and view information about each of the nodes in that prefixgroup.
Understanding IPv6 Status Information To monitor theaddress status of a device, the Advanced Routing SPI uses an IPv6 pingrather than using SNMP requests. The Advanced Routing SPI considersa 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 marksany 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 derivesinterface status from address status and node status from interfacestatus. From these address status, we derive interface status. The
Chapter 8248
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
Advanced Routing SPI also derives prefix group status from addressstatus. See Table 8-2 for a summary of how the Advanced Routing SPIcompounds IPv6 status information.
NOTE The status of an IPv4-compatible address contributes to the overallinterface status it is assigned to. This can also impact the overall nodestatus.
The Advanced Routing SPI derives interface status using thecompounding rules show in Table 8-3.
Table 8-2 Deriving IPv6 Status
Address Status Interface Status Node Status
Site-local addressstatus
Site-local interfacestatus
Site-local nodestatus
Global addressstatus
Global interfacestatus
Global node status
Site-local plusglobal addressstatus
Overall interfacestatus
Overall node status
Table 8-3 Compound IPv6 Address Status into Interface Status
Current Address Status CompoundedInterface Status
Any address status is down. Down
All address statuses are unknown. Unknown
At least one address status is up and allother address statuses are unknown.
Normal
Chapter 8 249
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
The Advanced Routing SPI derives interface status using thecompounding rules show in Table 8-4 on page 250
See the Understanding IPv6 Status section of the HP OpenView webonline help for more information.
Understanding IPv6 Events
The Advanced Routing SPI generates many new IPv6 events. Most ofthese events are logged and not forwarded to the NNM Alarm Browser.You can open an IPv6 view from events located in the NNM AlarmBrowser, by selecting Actions->Views->IPv6.
The Advanced Routing SPI displays one event, OV_IPV6_Address_DOWN,in the NNM Alarm Browser. NNM includes both theOV_IPV6_Address_DOWN and OV_IPV6_AddressUP events in thePairwise event correlation. For more information about the behavior ofthe NNM Event Correlation System and the Pairwise event correlation,
Table 8-4 Compounding IPv6 Address Status
Condition of Contributing Objects CompoundedStatus
No Objects Exist Unknown (blue)
All are unknown Unknown (blue)
All are up (except those that areunknown)
Normal (green)
One is down and all others are up(except those that are unknown)
Warning (cyan)
More than one is up and more than oneis down (except the ones that areunknown)
Minor/Marginal(yellow)
One is up and all others are down(except the ones that are unknown)
Major (orange)
All are down (except the ones that areunknown)
Critical (red)
Chapter 8250
The Advanced Routing Smart Plug-inRunning IPv6 Discovery
see Managing Your Network with HP OpenView Network Node Manager.For more information about events and their definitions, see thetrapd.conf manpage.
Supported Routers
See “Obtaining Supported Device Information” on page 276 forinformation about which devices the Advanced Routing SPI supports.
Chapter 8 251
The Advanced Routing Smart Plug-inRunning OSPF Discovery
Running OSPF DiscoveryRunning OSPF discovery results in the Advanced Routing SPIdiscovering OSPF information about your network.
During OSPF discovery, the Advanced Routing SPI reads informationfrom one of two OSPF version 2 MIBs: RFC1850 or RFC1253. Routingdevices must support one of these MIBs for the Advanced Routing SPI toread OSPF information from them.
During the OSPF discovery, the Advanced Routing SPI discovers whicharea OSPF devices are located in, and how these areas relate to oneanother.
You must manually run OSPF discovery as outlined in the followingprocedure:
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 theOspf.cfg file. Use the following guidelines to configure the Ospf.cfgfile.
• Add the IP address of a router being managed by NNM to seedOSPF discovery.
• You can set the OSPF discovery range using either an OSPF areaINCLUDE or EXCLUDE list, but not both, as shown in theOspf.cfg file.
• If you use an INCLUDE list, the Advanced Routing SPI discoversonly the areas in the INCLUDE list.
• If you use an EXCLUDE list, the Advanced Routing SPIdiscovers all areas except those on the EXCLUDE list.
2. Run the following script:
Windows: %OV_BIN%\ospfdis.ovpl
UNIX: $OV_BIN/ospfdis.ovpl
Chapter 8252
The Advanced Routing Smart Plug-inRunning OSPF Discovery
You must run ospfdis.ovpl each time you modify the Ospf.cfg filefor OSPF discovery changes to affect the OSPF view.
3. Once OSPF discovery completes with no errors shown on yourscreen, 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 mayimpact any devices or areas you are interested in viewing and rerunthe 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 environmentshould remedy problems found in the ospfdis.err file. Some commonOSPF discovery errors are:
• Device access problems: Device SNMP community strings aremissing or incorrect. Find and add the device community namesusing NNM’s SNMP Configuration menu item from the NNMOptions menu. This could be the source of numerous ospfdis.errfile entries.
• Seed device is inaccessible: Make sure the seed device you add to theOspf.cfg file has been discovered by NNM and is accessible from thesystem that the Advanced Routing SPI is running on.
• Discovered device is inaccessible: Make sure the device has beendiscovered by NNM and is accessible from the system the AdvancedRouting SPI is running on.
• No seed in the Ospf.cfg file: Edit the Ospf.cfg file and add a seedrouter IP address.
• The Advanced Routing SPI expecting IP addresses: Make sure theseed router IP address is valid.
• Using both INCLUDE and EXCLUDE area lists: Make sure youhave not configured both an INCLUDE and an EXCLUDE area list.
• INCLUDE or EXCLUDE area list errors: Make sure you configurethe lists correctly in the Ospf.cfg file.
Chapter 8 253
The Advanced Routing Smart Plug-inRunning OSPF Discovery
Using the OSPF View to Review NetworkConfigurations
The following scenario shows an example of using the Advanced RoutingSPI information to investigate an OSPF configuration question.
Suppose you wanted to make sure the Area Border Routers you set up foryour network were configured correctly. You know you configuredinterfaces on c8kloop to act as the Area Border Routers for both Area0.0.0.0 and Area 0.0.0.1 .
To check this, you could open an OSPF view from Home Base andinvestigate. Figure 8-1 and Figure 8-2 on page 255 show both areasconfigured as you designed them.
Figure 8-1 Checking the Area Border Router of Area 0.0.0.1
Chapter 8254
The Advanced Routing Smart Plug-inRunning OSPF Discovery
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 AllAreas tab. Figure 8-3 on page 256, shows some of the additionalinformation that is available. You can use this view to researchadditional information such as the OSPF link metric and router status.
Chapter 8 255
The Advanced Routing Smart Plug-inRunning OSPF Discovery
Figure 8-3 Additional Information from the All Areas Tab
Chapter 8256
The Advanced Routing Smart Plug-inRunning HSRP Discovery
Running HSRP DiscoveryHSRP permits two or more routers (in an HSRP Group) to act as a singlevirtual router. Routers in an HSRP Group share a virtual IP address anda virtual MAC address.
Each router has a corresponding actual IP address on the interface thatis participating in the HSRP Group.
For the HSRP feature to work well, the following conditions must betrue:
• NNM must not attempt to discover and manage the virtual IPaddress of an HSRP Group.
• NNM must manage the actual IP address of router interfaces in theHSRP Group.
NNM meets both of those conditions, internally tracking the virtual IPaddress of an HSRP group while managing the actual IP address ofrouter interfaces in the HSRP Group.
Checking NNM for Correct Handling of HSRP VirtualIP Addresses
To make sure NNM is configured for correctly handling HSRP virtualaddresses, 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 boldtext 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 virtualIP address correctly.
4. If the bold text is not present add the text and save the file. You alsoneed to restart the netmon process as follows:
Chapter 8 257
The Advanced Routing Smart Plug-inRunning HSRP Discovery
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 haveinstalled NNM and proceeded with an automatic discovery of yournetwork), and the contents of the netmon.lrf showsmigrateHsrpVirtualIP=false or doesn’t contain themigrateHsrpVirtualIP parameter, then the database is likely tocontain the virtual IP addresses of your HSRP groups. This is especiallytrue if you used NNM’s auto-discovery feature.
You have two tasks:
1. Verify that NNM is correctly managing HSRP virtual IP addresses inyour environment.
2. Remove from NNM any HSRP virtual IP addresses that NNMcurrently manages.
The next sections explain the procedure you should follow.
Verifying that NNM is Properly Managing HSRP Virtual IPAddresses
Follow the procedure shown in “Checking NNM for Correct Handling ofHSRP 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 existingNNM topology data. There are a couple of common ways to do this:
• Use the following command to completely delete the router from thedatabase (deleted routers get re-discovered in the next step, butwithout their virtual interfaces):
Windows: %OV_BIN%\ovtopofix -r
UNIX: $OV_BIN/ovtopofix –r
Chapter 8258
The Advanced Routing Smart Plug-inRunning HSRP Discovery
You should remove the node (using the NNM ID) rather than the IPaddress. 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 inNNM’s online help (or the UNIX manpages) for details on usingthese commands.
• Alternatively, from the NNM graphical interface (ovw), find each ofyour HSRP routers. Open each one to show all its interfaces. Deletethe interface that corresponds to the virtual IP address.
Validating Your Results
To verify that your HSRP discovery is correct, run another ExtendedTopology 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 foreach group and check for the following:
• If the HSRP virtual IP address shows up in both the IP Interfacecolumn and the Group Membership column, NNM is most likelymanaging the virtual IP address. You need to remove this interfacefrom NNM (see “Remove Virtual IP Addresses from the NNMTopology” on page 258).
• You may see an HSRP Group with only one router, even though anHSRP Group must have at least two routers. This could have severalcauses. To resolve the problem, do the following:
— Ensure that the actual IP address of the missing HSRP router isin 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
The Advanced Routing Smart Plug-inRunning HSRP Discovery
Note that if an HSRP router interface is down during discovery, theAdvanced Routing SPI will discover HSRP groups incompletely. Thisis because the HSRP MIBs at the time of discovery reflect the actualstate. This should be a transient problem that resolves when anExtended Topology discovery occurs after the interface is back up.
Understanding HSRP View Status Information
The Active Problem Analyzer polls HSRP routers and reports HSRPgroup status information. See Table 8-5 on page 261 for a list of thevarious group status colors and their meanings.
Chapter 8260
The Advanced Routing Smart Plug-inRunning HSRP Discovery
Table 8-5 HSRP Group Status
HSRPGroupStatus Color HSRP Group Status Description
Unknown(blue)
The HSRP group has not been polled sincediscovery completed, so the state of the group hasnot been determined yet.
The actual state of this HSRP group will bedisplayed as soon as it is polled.
Normal(green)
The HSRP group is correctly configured andoperational.
This HSRP group is providing routing functionality,and all standby routers are available.
Warning(cyan)
The HSRP group has an interface in the Activestate, and an interface in the Standby state, but italso has at least one interface that is not in theListen state.
This HSRP group is providing routing functionality.However, one or more standby routers are definitelyunavailable.
Minor orMarginal(yellow)
The HSRP Group has an interface in the Activestate, but there is no interface in the HSRP groupwhich is in the Standby state.
This HSRP group is providing routing functionality,but there is no standby router available.
Major(orange)
Multiple interfaces in the HSRP group are in theActive state, or multiple interfaces in the HSRPgroup are in the Standby state.
This HSRP group is not functioning correctly. Thereis almost certainly a problem with routingfunctionality.
Critical (red) The HSRP group has no interface in the Activestate.
This HSRP group is definitely not providing routingfunctionality.
Chapter 8 261
The Advanced Routing Smart Plug-inRunning HSRP Discovery
The Active Problem Analyzer displays the following alarms in the alarmsbrowser.
• OV_HSRP_No_Active: The reported HSRP group is completelyinoperational.
• OV_HSRP_Multiple_Active: The reported HSRP group is in anabnormal condition as there are multiple active interfaces.
• OV_HSRP_No_Standby: The reported HSRP group has no standbyinterface.
• OV_HSRP_Degraded: The reported HSRP group has an interface thatis not functioning properly
• OV_HSRP_FailOver: The reported HSRP group has changed it activeinterface.
• OV_HSRP_Standby_Changed: The reported HSRP group has changedits standby interface.
• OV_HSRP_Normal:The reported HSRP group is now functioningnormally.
See the trapd.conf reference page in NNM’s online help (or the UNIXmanpage) for more information.
Potential Status Anomalies
Subtle conditions can lead the Advanced Routing SPI to yield unexpectedstatus for HSRP groups.
• If you run an Extended Topology discovery while any HSRP groupinterfaces are down, Extended Topology will not discover all of theHSRP group interfaces and will calculate and display HSRP groupstatus using incomplete information. Once you run an ExtendedTopology discovery that finds all of the HSRP group’s routerinterfaces, Extended Topology will show accurate HSRP status.
CAUTION As you add equipment with new HSRP virtual IP addresses to yourmanaged environment, you need to add these addresses to thenetmon.noDiscover file prior to turning on the new equipment. If you
Chapter 8262
The Advanced Routing Smart Plug-inRunning HSRP Discovery
fail to do this, and NNM discovers these virtual IP addresses, you willneed to complete the tasks explained in“HSRP Discovery withPre-existing NNM Topology” on page 258.
Using the HSRP View to Diagnose Network Problems
The following scenario gives one example of using Extended Topologyinformation to diagnose an network problem with HSRP. This discussionassumes you are familiar with HSRP. For detailed information aboutHSRP, refer to RFC2281.
Suppose you have two directly connected router interfaces, interface a onrouter 1 and interface b on router 2. This discussion refers to theserouter interfaces as interfaces 1.a and 2.b respectively.
Assume both interfaces are located within the same LAN segment. Youhave router interface 1.a configured as active and router interface 2.bconfigured as standby for standby group a.b.c.d. a.b.c.d represents thevirtual 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_FailOveralarm.
2. To investigate this alarm, you open an HSRP Group view by selectingthe OV_HSRP_Failover alarm in the Alarm Browser and use theActions:Views-> HSRP Group Detail menu.
3. The HSRP Group Detail view shows you that interface 2.b is nowactive and interface 1.a is down. You need to troubleshoot interface1.a.
Chapter 8 263
The Advanced Routing Smart Plug-inFor More Information
For More InformationIf you need more information about IPv6 and OSPF concepts, thefollowing 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: NewRiders Publishing, 1997. To order, reference ISBN 1-56205-652-2.
Loshin, Pete. IPv6 Clearly Explained. San Francisco, CA: MorganKaufmann Publishers, Inc., 1999. To order, reference ISBN0-12-455838-0.
Chapter 8264
9 Diagnosing Network Problemswith Extended Topology
Chapter 9 265
Diagnosing Network Problems with Extended TopologyViewing Extended Topology and NNM Views Using the NNM Alarm Browser
Viewing Extended Topology and NNM ViewsUsing the NNM Alarm BrowserAlarms arriving in the NNM Alarm Browser often point you to networkaccess problems. Extended Topology helps you troubleshoot networkaccess problems caused by a device malfunction or configuration error.
This chapter presents several examples of how you might use ExtendedTopology to diagnose network problems. These examples are shorttroubleshooting scenarios, and do not show all of the many ways to useExtended Topology to troubleshoot your network.
Using the Neighbor View to Diagnose NetworkProblems
The following scenario gives an example of using Extended Topologyinformation to diagnose a network problem.
Suppose you saw the highlighted alarm in Figure 9-1 on page 267 in yourNNM Alarm Browser. It seems to indicate a problem with one of yourrouters.
Chapter 9266
Diagnosing Network Problems with Extended TopologyViewing Extended Topology and NNM Views Using the NNM Alarm Browser
To investigate, you could open an NNM Neighbor view by highlightingthis 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. Noticethe fat trunk line between 4kfcc5lc5m08 and hp24m2sw. Placing yourmouse pointer over this trunk line shows you that two ports on eachdevice 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. Thatindicates the device status is marginal.
Chapter 9 267
Diagnosing Network Problems with Extended TopologyViewing Extended Topology and NNM Views Using the NNM Alarm Browser
Figure 9-3 shows that by placing your mouse pointer over the port on4kfcc5lc5m08 that connects to hp24m2sw, you can obtain moreinformation about the problem. Board 3 port 23 on 4kfcc5lc5m08 eitheris disabled and must be enabled, or the port is physically disconnectedfrom 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 Topologyinformation to diagnose a network problem.
Suppose you saw the two alarms in Example 9-4 on page 269 in yourNNM Alarm Browser. It seems to indicate a traffic problem with yournetwork.
Chapter 9268
Diagnosing Network Problems with Extended TopologyViewing Extended Topology and NNM Views Using the NNM Alarm Browser
To investigate, you could open two NNM Neighbor views by highlightingeach of these alarms in the Alarm Browser and using theActions:Views->Neighbor menu.
Figure 9-4 The Threshold Exceeded Alarms to Investigate
Figure 9-5 shows two Neighbor views. Notice the port informationdisplayed in each view when the mouse pointer is placed over the porticons on either hp24m1sw or 212swtch. This shows you that ntctst20 isconnected to hp24m1sw board 1 port 2 and that vanguard is connected to212swtch board 1 port 1.
Figure 9-5 Viewing the Switched Ports
Chapter 9 269
Diagnosing Network Problems with Extended TopologyViewing Extended Topology and NNM Views Using the NNM Alarm Browser
You recognize ntctst20 and vanguard as two test machines from anisolated test environment that generates lots of traffic. Your recordsshow that you configured devices in this test environment to participatein VLAN 10 and assigned ntctst20 and vanguard to ports on cisco0.Someone apparently disconnected them from cisco0 and reconnectedvanguard and ntctst20 to other switches.
You could open a VLAN view from Home Base to see if any ports on212swtch and hp24m1sw are participating in VLAN 10 (see Figure 9-6 onpage 271). You notice that neither 212swtch or hp24m1sw have portsparticipating in VLAN 10. If there were a lot of VLANs in this view, youcould use the View:Find command to search for VLAN 10.
Figure 9-6 shows the ports from each switch that participate in aspecified VLAN. You could use this view to identify all of the portsparticipating in VLAN 10. You could then select new ports for bothntctst20 and vanguard and move these devices to remedy the trafficproblem.
NOTE Some VLAN views could show duplicate VLAN names. ExtendedTopology distinguishes between VLANs which have identical names butwhich reside on separate broadcast domains. See the HP OpenView webonline help for more information.
Chapter 9270
Diagnosing Network Problems with Extended TopologyViewing Extended Topology and NNM Views Using the NNM Alarm Browser
Figure 9-6 Viewing VLANs with the VLANs View
Chapter 9 271
Diagnosing Network Problems with Extended TopologyLaunching Specific Views or URLs from Alarms
Launching Specific Views or URLs fromAlarmsYou can configure Extended Topology to access a specific web locationfrom an event in the Alarm Browser. You can configure up to 50 URLs inthe xnmeventsExt.conf file for the Actions:Views menu. You canalready access Extended Topology views from Alarm Browser events,however these new URLs can be any other URL that you prefer. NNMand Extended Topology views are available from NNM’s Tools menu orfrom 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 changesto 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.
Chapter 9272
Diagnosing Network Problems with Extended TopologyLaunching 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. TheActions:Views menu in the Alarm Browser should contain the newmenu items.
Chapter 9 273
Diagnosing Network Problems with Extended TopologyCalculating Detailed Layer 2 and Layer 3 Information for ECS
Calculating Detailed Layer 2 and Layer 3Information for ECSExtended Topology calculates layer 2 and layer 3 network paths betweenthe Extended Topology management station and each managed device.This information is used by the netmon process, ECS, and theConnectorDown correlation to provide better layer 2 and layer 3diagnostic information in node down situations.
Chapter 9274
10 Maintaining Extended Topology
Chapter 10 275
Maintaining Extended TopologyMaintaining Extended Topology
Maintaining Extended TopologyTo maintain your Extended Topology application, you may need toperform one or more of the following tasks.
Checking for Extended Topology Patch Releases
Check the OpenView web site for the latest patch releases or supportupdates. 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 followingdirectory:
• 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. SeeManaging Your Network with HP OpenView Network Node Manager formore information.
Obtaining Supported Device Information
Extended Topology collects device information from specific MIBscontained in discovered devices and uses this information to displayDynamic Views.
To obtain a list of devices, MIBs, and connectivity information thatExtended 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 collectsdevice information from new device models you deploy.
Chapter 10276
Maintaining Extended TopologyMaintaining Extended Topology
Troubleshooting Extended Topology Discovery
Discovery can take several hours to complete. This length of timedepends on network size, network traffic, the processing power of theNNM management station, and how you configure your discovery zones.
If discovery takes longer that normal to complete and you use zones inyour discovery process, use the [Test Zone Configuration] button totest your zones. This tests your configuration and may makerecommendations that might improve your discovery.
If you suspect you are having problems with Extended Topologydiscovery, you can view discovery status details by running the followingcommand:
• 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 duringdiscovery, see Example 10-1.
Example 10-1 Output of ovstatus -v ovet_disco During Discovery
object manager name: ovet_discostate: RUNNINGPID: 28818last message: Discovery started: Mon Nov 19 10:44:16 2002.exit status: -additional info:
The additional info field in Example 10-1 may report differentmessages, such as:
Discovery started: time discovery started.
Entered Phase 1: Access testing quantity of nodes for ET.discovery (quantity ofnodes completed).
Entered Phase 1: Collecting device attributes from node quantity nodes in zoneIPV6.
Entered Phase 1: Collecting device attributes from node quantity nodes in zoneDEFAULT.
Entered Phase 1: Collecting device attributes from qnode uantity nodes in zonezone number.
Chapter 10 277
Maintaining Extended TopologyMaintaining Extended Topology
Entered Phase 2: Collecting environment attributes from node quantity nodes inzone IPV6.
Entered Phase 2: Collecting environment attributes from node quantity nodes inzone DEFAULT.
Entered Phase 2: Collecting environment attributes from node quantity nodes inzone zone number.
Entered Phase 3: Collecting connectivity data from node quantity nodes in zoneIPV6.
Entered Phase 3: Collecting connectivity data from node quantity nodes in zoneDEFAULT.
Entered Phase 3: Collecting connectivity data from node quantity nodes in zonezone number.
Final collection phase completed. Now calculating connectivity for node quantitynodes in zone IPV6.
Final collection phase completed. Now calculating connectivity for node quantitynodes in zone DEFAULT.
Final collection phase completed. Now calculating connectivity for node quantitynodes in zone zone number.
Connectivity calculation completed. Now creating topology for node quantitynodes in zone IPV6.
Connectivity calculation completed. Now creating topology for node quantitynodes in zone DEFAULT.
Connectivity calculation completed. Now creating topology for node quantitynodes in zone zone number.
Discovery completed and processes stopped until next discovery: time discoverycompleted.
Awaiting next discovery cycle.
When Extended Topology has finished discovery, the message in theadditional info field is Awaiting next discovery cycle, and onlythat message is displayed until the next discovery cycle begins.
If you never see the Awaiting next discovery cyclemessage or if theoutput of the ovstatus -v ovet_disco command differs from theexample above, you may want to restart Extended Topology discovery byrunning the following command:
• Windows: %OV_BIN%\etrestart.ovpl
• UNIX: $OV_BIN/etrestart.ovpl
Chapter 10278
Maintaining Extended TopologyMaintaining Extended Topology
Troubleshooting Additional Problems
Some of the last messages from the ovstatus -v ovet_discocommand could point to or duplicate entity errors or database errors. Toresolve these errors use the following information.
Resolving Duplicate Entity Errors If you see the following errormessage, you may have entered incorrect HSRP information.
Duplicate entity error - before restarting discovery, consult Using ExtendedTopology manual for trouble-shooting steps (HSRP Virtual IP Address)
Notice that the IP address at the end of the message is the HSRP virtualIP 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 followingactions:
• You manually moved devices between or among zones, and then onlyinitiated the discovery of a single zone. To remedy this you need toinitiate a full discovery. See “Manually Configuring Zones” onpage 26 for more information.
• You chose to complete an automatic zone configuration, and thenonly initiated the discovery of a single zone. To remedy this you needto initiate a full discovery. See “Automatic Zone Configuration” onpage 24 for more information.
Resolving Database Errors If you see the following error message,you have encountered some database problems that you may be able toresolve.
Database error - before restarting discovery, consult Using Extended Topologymanual 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 needto free up (or add) some disk space.
2. Run the ovstatus ovdbcheck command and follow the displayedinstructions.
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
Maintaining Extended TopologyMaintaining Extended Topology
Troubleshooting Extended Topology Views
You may encounter problems with views, such as the view not appearingor the view not presenting all the expected data. See the TroubleshootingViews section of the HP OpenView web online help for more informationabout Troubleshooting Extended Topology views.
In certain circumstances where device information is limited, ExtendedTopology may not accurately discover and model every connection in anetwork. As a result, you may see no connections where you knowconnections exists, or connections indicated where you know none exist.You can use the Connection Editor functionality to correct thisinformation. See Appendix C, “Modifying Connections with theConnection Editor,” on page 301 for more information.
Chapter 10280
A Common Zone ConfigurationExamples
Appendix A 281
Common Zone Configuration Examples
Network designers deploy various enterprise network designs to meettheir customers' requirements.The network designs described in thisappendix contain patterns that can be used to plan and configure theExtended Topology discovery.
Appendix A282
Common Zone Configuration ExamplesCampus Environment Scenario
Campus Environment ScenarioSuppose you are managing the modern campus environment shown inFigure 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 inFigure A-2 on page 284
Appendix A 283
Common Zone Configuration ExamplesCampus Environment Scenario
Figure A-2 Core Block
NOTE The VLAN numbering shown in Figure A-2 is only a sample. The accessswitches can, and probably will, have overlapping VLAN IDs. Assumethat you create DNS names for devices based upon geography for thisenterprise network (for example switch.bldg4.atlanta.company.com).Figure A-2, “Core Block,” shows a redundant network to betterdemonstrate how to configure Extended Topology zones for more efficientand accurate discovery.
The rest of this appendix discusses zone discovery configurations thatrefer to the network models shown inFigure A-1. You can interchangethe terms buildings, locations, or sites depending on the size of yourcompany.
Appendix A284
Common Zone Configuration ExamplesGeneral guidelines
The following strategies can be replicated for all campuses of theenterprise. The following discussion does not go into any detail for WANblock designs, since Extended Topology is designed to discover layer 2and other protocol information. It does not discover WAN information.
General guidelinesDo 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 VLANnames or IDs)
Separating the above equipment into separate zones will result ininaccurate discoveries. You can place a router in multiple zones to avoidseparating it.
Extended Topology discovers router-to-router connectivity informationonly if routers support CDP. If your routers don’t support CDP, it doesn’tmatter how you divide them up, as Extended Topology cannot obtainconnectivity information from routers not supporting CDP.
If you don't need to view router connectivity within the ExtendedTopology neighbor view, configure the core routers in as few zones aspossible.
If the network size in each building is too small, combine the networks oftwo or more buildings to get a bigger zone. Add the core routers for eachbuilding into that zone.
Based on OpenView tests, you may want to start with zones of 200 nodesor less. The OpenView tests discovered devices with port densities of 24,and were run on HP C3000 and Sun Ultra 60 workstations with 512 MBof RAM. However, in some environments successful discoveries can haveup to four times that many devices in a zone. You might want toexperiment to decide what zone size works best for you, based on thefollowing parameters:
• The port densities of the devices you plan to discover.
Appendix A 285
Common Zone Configuration ExamplesSpecific 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 yourzones.
Specific guidelinesThese guidelines are for some sample network types that may becommonly deployed.
Possibility 1: Core Devices are Routers
• The network contains core devices that are all routers.
• Campus buildings/sites are mostly switched, with router interfacesplaced between switch blocks or VLANs.
Appendix A286
Common Zone Configuration ExamplesSpecific guidelines
Figure A-3 Core is Routed
Suggested zone configuration
• To configure discovery for the switch-to-switch and switch-to-routerconnectivity, do the following:
Refer to Figure A-3, “Core is Routed,” for this discussion. Put all ofthe access switches, distribution switches/routers, and core router(s)that service the building into zone 1 using the name wildcard methodfor defining a zone. Using this method, you can create a zone forevery building in your campus, provided it meets the above criteria.
• To configure discovery for the router-to-router connectivity, do thefollowing:
Switches
Router
Switches
Servers/PCs
Router
Servers/PCs
Core Core
Zone 2 Zone 3
Zone 1 Routers
Appendix A 287
Common Zone Configuration ExamplesSpecific guidelines
Refer to Figure A-3, “Core is Routed,” for this discussion. Configurethe core routers into one zone by themselves. Splitting the corerouters into multiple zones may increase management traffic frombordering routers to the core routers for each zone you add the corerouters to. You should split large core routers into a few zones tospeed up discovery. Doing this will speed up discovery at the cost ofhigher management traffic. It is a design choice that you need tomake at zone configuration time.
Appendix A288
Common Zone Configuration ExamplesSpecific 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 interfacesplaced between switch blocks and/or VLANs.
Figure A-4 Core is Switched: Using Two Zones
Router
Switches
Servers/PCs
Router
Switches
Servers/PCs
Core Core
Zone 2
Zone 1 Switches
Appendix A 289
Common Zone Configuration ExamplesSpecific guidelines
Figure A-5 Core is switched: Using One Zone
Suggested zone configuration
• Refer to Figure A-4, “Core is Switched: Using Two Zones,”andFigure A-5, “Core is switched: Using One Zone,”for this discussion.To configure discovery for switch-to-switch, and switch-to-routerconnectivity, do the following:
Follow the same specific guidelines as defined in Possibility 1 forgetting switch-to-switch, and switch-to-router connectivity in theswitch blocks of various buildings.
Also, since the core devices are switches now, you should place all ofthe core devices and the corresponding distribution and WAN routersin the same zone for that building.
Router
Switches
Servers/PCs
Router
Switches
Servers/PCs
Core Core
Zone 1
Switches
Appendix A290
Common Zone Configuration ExamplesSpecific guidelines
If your entire network is very small you can place all of your devicesin one zone as shown in Figure A-5 on page 290. However, ifExtended Topology recommended that you use multiple zones whenyou 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 thefollowing:
Since the network type is mostly switched except for the distributionand WAN layers, and the distribution layer routers are connected toswitches, the only router connectivity that is left to be discovered isWAN to WAN router connectivity. WAN routers typically won’t runCDP, hence you can break up the WAN routers as you wish.
Appendix A 291
Common Zone Configuration ExamplesSpecific guidelines
Appendix A292
B Successfully DeployingExtended Topology: PracticalDeployment Tips
Appendix B 293
Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips
Extended Topology Deployment TipsOpenView engineers compiled some simple, yet important ExtendedTopology deployment tips. For better understanding, read through theExtended Topology manual prior to reviewing the following information.It is recommended that you read through this entire list of deploymenttips prior to running your first Extended Topology discovery.
Prediscovery Tips
Below is a list of activities that you may want to complete prior torunning your first Extended Topology discovery.
• It is much easier to discover devices and connectivity on a healthynetwork. The support directory contains tools to help you understandthe health of your NNM installation. Scripts such as checkDNS.ovpland resolveNames.ovpl can be extremely helpful. You can findsupport tools in the following (support) directory:
— Windows:%OV_MAIN_PATH%\support
— UNIX: $OV_MAIN_PATH/support
• You should research whether Extended Topology can discoverinformation about the devices on your network. You can do this byviewing the device list or the supported MIBs for a family of devicesat the following URL:http://www.openview.hp.com/go?id=nnmet&page=1.
If your network contains unsupported devices, you may want to runyour first Extended Topology discovery without these nodes. You canuse the bridge.noDiscover file to stop Extended Topology fromdiscovering device information about these nodes. See “LimitingExtended Topology Discovery” on page 32, or the bridge.NoDiscoverreference page in NNM’s online help (or the UNIX manpage) formore information.
NOTE If you choose to run your discovery and include these nodes, theseunsupported devices may cause problems.
Appendix B294
Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips
• You should not allow Extended Topology to discover deviceinformation about managed hubs. You should enter any managedhubs in the bridge.noDiscover file. This file doesn’t supportsysObjectID filters so you will need to work with NNM’sovtopodump tool to get the node list. See the ovtopodump referencepage in NNM’s online help (or the UNIX manpage) for moreinformation.
• It is a good idea to start your first Extended Topology using only asmall quantity (10-20 nodes) of directly connected nodes. It is best totarget networking nodes such as switches and routers. You couldinclude a pair of routers that support HSRP routers too. You shouldknow their topology so you can validate the results. Anotheradvantage of a small test run is that you don’t need to worry aboutzone definitions.
• If you want to avoid using complex Extended Topology filters, youcan use the following approach to create a small NNM databasecontaining only a few nodes:
1. Use the loadhosts tool to build a small database. See theloadhosts reference page in NNM’s online help (or the UNIXmanpage) for more information.
2. After loading nodes with the loadhosts tool, run annmdemandpoll nodename on each node to speed up NNM’sconfiguration poll. See the nmdemandpoll reference page inNNM’s online help (or the UNIX manpage) for more information.
3. After you complete loading these nodes, run, as root orAdministrator, the setupExtTopo.ovpl script to configureExtended Topology and start your discovery. See thesetupExtTopo.ovpl reference page in NNM’s online help (or theUNIX manpage) for more information.
• Before running your first Extended Topology discovery, you need tounderstand your network topology. You should understand thefollowing 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
Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips
You’ll be more confident in the Extended Topology discovery results ifyou can compare them to the actual topology.
• There are several protocols that can help Extended Topologydiscovery layer 2 more accurately. For example, if the Cisco deviceson your network support CDP and the Extreme Network devices onyour network support EDP, then your layer 2 connectivity should bemuch more accurate.
• Networks that have low traffic levels are much more difficult todiscover. This is due to switches in this low traffic area having emptyForwarding Database (FDB) Tables.
To remedy this, run your Extended Topology discovery when thenetwork is active. If you must run your Extended Topology discoveryduring low traffic times, telnet onto the switches shortly beforeExtended Topology discovery and ping the adjacent switches. Thiswill fill the FDB tables. If your switches support CDP or EDP, thismay not be necessary.
• If you run OSPF in your network, and you have purchased andinstalled a license for the Advanced Routing SPI, then you need torun an OSPF discovery separately from a normal Extended Topologydiscovery. It is important to understand that Extended Topology onlydiscovers OSPF nodes that are currently managed by ExtendedTopology.
You will probably want to run an OSPF discovery against your largenetwork, as running this discovery with only a small test networkwill probably not be successful. A nice debug approach is to runospfdis.ovpl dbg=1. See “Discovering OSPF Information” onpage 238 for more information.
Discovery Tips
Below is a list of activities that you should complete in order tosuccessfully run your first Extended Topology discovery.
• After you have used the relevant information in the PrediscoveryTips section, you are ready to run your first Extended Topologydiscovery. If you have not enabled Extended Topology, run, as root orAdministrator, the setupExtTopo.ovpl script. Answer yes toquestions about enabling the appropriate agents. After this scriptcompletes, an Extended Topology discovery begins.
Appendix B296
Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips
If you enabled Extended Topology earlier, then, as root orAdministrator, run the etrestart.ovpl script to run a newExtended Topology discovery. See the etrestart.ovpl reference page inNNM’s online help (or the UNIX manpage) for more information.
TIP You can use the -verbose option with the etrestart.ovpl script toshow process status messages.
• To make sure that the entries in your bridge.noDiscover file areworking 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 ExtendedTopology will discover information. This file is updated at thebeginning of each Extended Topology discovery.
As an example of how to monitor the hosts.nnm file, suppose thatyou expected your filters to target an Extended Topology discovery ofonly 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 theHome Base page from a browser. To do this, open the ExtendedTopology Configuration GUI using the NNM Options: ExtendedTopology Configuration menu or select the Discovery Statustab from Home Base. If you are having problems getting Home Baseto come up, try the following:
— Make sure you have the right JPI installed.
— Launch Home Base from another computer. If this works, look fordifferences in your browser settings.
— Proxy Servers can cause some problems for Home Base. Tryrunning without the Proxy Server and see if that helps.
— Try clearing the cache on your browser and clearing the cache inyour JPI (done via the control panel in Windows).
— Another common problem you could encounter is an improperlyconfigured domain name resolution (DNS) server. The browsermust be able to resolve the DNS name of the Extended Topology
Appendix B 297
Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips
server. This problem usually manifests itself with ExtendedTopology displaying a blue box without loading the DynamicViews 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 (likefoo.hp.com). If it returns a short name, you should changeyour DNS server configuration or your hosts file on theExtended Topology server to remedy this problem. After yourname resolution is working properly, you need to, as root orAdministrator, re-run the setupExtTopo.ovpl script.
Post Discovery Tips
Below is a list of activities that you will want to complete after runningyour first Extended Topology discovery.
• After discovery completes, go to Home Base and select theDiscovery Status tab. From there, select [View TopologySummary] and review the results.
1. Review the number of Layer 2 and VLAN connections. Were anyfound during the discovery? If not, then something went wrongduring the discovery. Extended Topology needs SNMP access todevices in order to complete an accurate discovery. You shouldcheck for nodes that didn’t respond to SNMP by using thefollowing 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 SNMPConfiguration user interface (UI). You can access the SNMPConfiguration UI using NNM’s Options: SNMP Configurationmenu. Extended Topology will apply any changes you make to itsnext discovery.
Appendix B298
Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips
• Another useful tool to examine the results of the discovery is listedbelow:
— 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 seehow they look.
— From Home Base, try running a neighbor view from one of yourswitches.
— If you are happy with your views and want to try a full discovery,now is a good time to have Extended Topology discover yourentire network.
— If you would rather take a more conservative second step whensetting up a more extensive Extended Topology discovery,consider creating a medium size discovery with a few hundrednodes.To do this, you would remove specific switches and routersfrom the bridge.noDiscover file or you could modify some ofyour zone definitions. Go through the same analysis previouslydescribed to validate your discovered devices as you did in priorsteps. Make sure you don’t leave out critical network devices andend up with connectivity gaps.
In certain circumstances where device information is limited, ExtendedTopology may not accurately discover and model every connection in anetwork. As a result, you may see no connections where you knowconnections exists, or connections indicated where you know noneexist.You can use the Connection Editor functionality to correct thisinformation. See Appendix C, “Modifying Connections with theConnection Editor,” on page 301 for more information.
Appendix B 299
Successfully Deploying Extended Topology: Practical Deployment TipsExtended Topology Deployment Tips
Appendix B300
C Modifying Connections with theConnection Editor
Appendix C 301
Modifying Connections with the Connection EditorAn Overview of the Connection Editor Functionality
An Overview of the Connection EditorFunctionalityIn certain circumstances where device information is limited, ExtendedTopology may not accurately discover and model every connection in anetwork. As a result, you may see no connections where you knowconnections exist, or connections indicated where you know none exist.
NOTE Be careful in your assessment of connection accuracy. Extended Topologyfrequently surprises network administrators by showing that thenetwork’s actual topology differs from expectations. Before using thefacilities described here, make sure that your changes reflect the truetopology, and not merely what is believed about it.
To modify Extended Topology’s connection information, you first createthe connectionEdits file, and then add and delete specific connectionsby making entries in that file. This appendix describes the procedure indetail.
IMPORTANT Some device configuration activities cause SNMP agents to renumberthe interfaces of some Ethernet switches and routers. These activitiesinclude 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 discoveredconnections for these nodes. If you do, you will have to modify the entriesfor that device in the connectionEdits file each time the device’sinterfaces are renumbered.
Appendix C302
Modifying Connections with the Connection EditorAn Overview of the Connection Editor Functionality
At the end of its work, the ovet_disco process uses theconnectionEdits file to modify the discovered topology data. You canalso apply connection edits to the data from a previous discovery usingthe ovet_topoconnedit.ovpl script.
Appendix C 303
Modifying Connections with the Connection EditorUsing the Connection Editor
Using the Connection EditorExtended Topology uses the ovet_disco process to collect connectivityinformation from network infrastructure devices (connectors) and othernon-connector devices (end nodes) such as servers, workstations, or PCs.This information includes device attributes and their relationships toother devices in the network.
Extended Topology uses this information to show you how your devicesinterconnect. You can amend or remove device connections during thecourse of a discovery, or after a discovery has completed by creating andmodifying 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 thenames of interfaces located on connectors and end nodes. Theseinterfaces must already exist in the extended topology, or must bediscovered by the ovet_disco process.
You can add interfaces to the connectionEdits file using the followingform:
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 subsetof SQL statements. These OQL statements have extensions forcontrolling extended topology operations and are used internally duringExtended Topology discovery to create or delete connectionrepresentations. The following example shows the format of an OQLinsert statement in the connectionEdits file:
Appendix C304
Modifying Connections with the Connection EditorUsing the Connection Editor
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 bothdevices 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 ishelpful 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 fileto meet your specific needs.
• Suppose you want to comment on the connection between twoconnected devices, SwitchA and SwitchB, but do not want ExtendedTopology to take any action. In this example, both devices useifIndex 91. You could add the following line to theconnectionEdits file:
insert into disco.connectionEdits (m_Name, m_NbrName, m_Command) values(‘SwitchA.hp.com[ 0 [ 91 ] ]’, ‘SwitchB.hp.com[ 0 [ 91 ] ]’, 0);
• Suppose you want to configure Extended Topology to show theconnection between two connected devices, SwitchA and SwitchB. Inthis example, both devices use ifIndex 91. You could add thefollowing line to the connectionEdits file:
insert into disco.connectionEdits (m_Name, m_NbrName, m_Command) values(‘SwitchA.hp.com[ 0 [ 91 ] ]’, ‘SwitchB.hp.com[ 0 [ 91 ] ]’, 1);
• Suppose you wanted to remove an invalid connection between twodevices, SwitchA and SwitchB. In this example, both devices useifIndex 91.You could add the following line to theconnectionEdits file:
Appendix C 305
Modifying Connections with the Connection EditorUsing the Connection Editor
insert into disco.connectionEdits (m_Name, m_NbrName, m_Command) values(‘SwitchA.hp.com[ 0 [ 91 ] ]’, ‘SwitchB.hp.com[ 0 [ 91 ] ]’, 2);
Helpful Tools
There are several tools that can help you create and modify theconnectionEdits file. These tools are located in the followingdirectories:
• Windows:%OV_MAIN_PATH%\support\NM
• UNIX: $OV_MAIN_PATH/support/NM
NOTE The tools in the above directory are made available for HP supportengineers, and are not designed or tested for end-users. They aredescribed here because you may find them helpful, but Hewlett-Packardoffers no support for them.
Identifying the ifIndex
Switch vendors use various schemes to map physical ports to ifIndexvalues. Some vendors number their ports sequentially starting at 1 andhave a one-to-one mapping of port numbers to ifIndex values. Somevendors label the port numbers based on its position on the board onwhich 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 schemeto 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 informationinto the ifDescr or ifName objects reported by the SNMP agent. To seethese relationships, you can use the following command:
ovet_topoquery getNodeByName node-name
Look for the Description in the NMInterface sections of the output or theIfName, BoardNo and PortNum fields in the Interface Propertysections of the output. Use the IfIndex or EntityName field of thatoutput to determine the appropriate ifIndex value to use in theconnectionEdits file.
Appendix C306
Modifying Connections with the Connection EditorUsing the Connection Editor
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 theirconnected interfaces. NNM and Extended Topology use the valuesupplied in the SNMP MIB table ipaddrTable to link IP addresses toifIndex. You can use the following command to see theIP-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 addinginsert statements into the connectionEdits file. You must run thesetools as Administrator or root.
• ovet_topoconndump.ovpl script
You can use the ovet_topoconndump.ovpl script prior to addinginsert statements to the connectionEdits file. When used withoutany parameters, it will dump all the layer 2 connections currently inthe extended topology in the form of OQL insert statements into thedisco.connectionEdits table.
You can also use the -node parameter with theovet_topoconndump.ovpl script to display the layer 2 connectionsassociated 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 theovet_topoconndump.ovpl script:
— If you run the ovet_topoconndump.ovpl script with noarguments, Extended Topology displays all layer 2 connections inthe extended topology.
Appendix C 307
Modifying Connections with the Connection EditorUsing the Connection Editor
— If you run ovet_topoconndump -node hp4k1sw.hp.com,Extended Topology displays the layer 2 connections associatedwith hp4k1sw.hp.com. You can capture the text from this displayand use it as a starting point for creating your connectionEditsfile. The output would look something like this:
insert into disco.connectionEdits (m_Name, m_NbrName, m_Command) values(‘hp4k1sw.hp.com[ 0 [ 91 ] ]’, ‘hp4k2sw.hp.com[ 0 [ 91 ] ]’, 0);
insert into disco.connectionEdits (m_Name, m_NbrName, m_Command) values(‘hp4k1sw.hp.com[ 0 [ 81 ] ]’, ‘hp212sw.hp.com[ 0 [ 18 ] ]’, 0);
insert into disco.connectionEdits (m_Name, m_NbrName, m_Command) values(‘cisco5500.hp.com[ 0 [ 6 ] ]’, ‘hp4k1sw.hp.com[ 0 [ 17 ] ]’, 0);
NOTE Notice that Extended Topology includes the number 0 (the firstcharacter to the right of the left square bracket following eachfully qualified node name) in each entry line item. Do not removeor modify the number 0 when adding inserts into yourconnectionEdits file. The O character is reserved for future useand is not currently used.
• ovet_topoconnedit.ovpl script
You can use the ovet_topoconnedit.ovpl script to make changes in anexisting extended topology without running a discovery. Theovet_topoconnedit.ovpl script reads the connectionEdits file andupdates the extended topology database. Extended Topology silentlyignores invalid or duplicate entries contained within theconnectionEdits file.
You must stop and restart the embedded OpenView application server,ovas, to see the results of the applied changes. You should also restartthe ovet_poll process in order to inform it of any interface connectivitychanges 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.
4. Press Return or Enter.
Appendix C308
Modifying Connections with the Connection EditorUsing the Connection Editor
5. As Administrator or root, type ovstart ovas.
6. Press Return or Enter.
7. As Administrator or root, type ovstart ovet_poll.
8. Press Return or Enter.
Practical Examples
The following examples depict some actual connectivity problems andpotential solutions using the connectionEdits file.
Example C-1 Making Map Modifications
Refer to Figure C-1 on page 310 for this example. Suppose ExtendedTopology "discovers" a connection between SwitchA and SwitchB thatdoesn’t actually exist. For a number of reasons, including accurateroot-cause analysis, you want to remove that connection from topology.
You can use the following procedure to remove the connection betweenSwitchA to SwitchB from future discoveries:
1. As Administrator or root, run the following command: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);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘SwitchB.hp.com[ 0 [ 91 ] ]’,’hp4k1sw.hp.com[ 0 [ 91 ] ]’,0);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘hp4k1sw.hp.com[ 0 [ 91 ] ]’,’hp4k2sw.hp.com[ 0 [ 91 ] ]’,0);
Notice that the above display that describes a connection betweenifIndex 56 of hp4k1sw to ifIndex 1 of SwitchA.
2. Edit the connectionEdits file and add the following text:
insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘SwitchA.hp.com[ 0 [ 1 ] ]’,’hp4k1sw.hp.com[ 0 [ 56 ] ]’,2);
Appendix C 309
Modifying Connections with the Connection EditorUsing the Connection Editor
Notice that the value for the m_Command field of the insertstatement 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 anactual connection between SwitchB and SwitchA.
You can use the following steps to add this connection to futurediscoveries:
1. Determine which ifIndex value of SwitchB to use for theconnection. For this example, assume that port B2 is used onSwitchB. As Administrator or root, run the following command:
ovet_topoquery getNodeByName SwitchB.hp.com
Running the above command results in the following display:
::+++++++++++++++++ NMInterface ++++++++++++++
Appendix C310
Modifying Connections with the Connection EditorUsing the Connection Editor
ObjID:2d037786-f5c1-71d7-11b6-0f0276230000NNMObjID:764EntityName:SwitchB.hp.com[ 0 [ 42 ] ]Description:B2::==========Interface Property===============VPI:0VCI:0BoardNo:BPortNum:2AuxPortNum:42IfIndex:42IfName:B2IfAlias:-IfType:6PhysicalAddress:00:30:C1:EF:13:D7::
By looking at the information listed in the above output, youdetermine that you should use ifIndex value 42 for SwitchB.
2. Determine which ifIndex value of SwitchA to use for theconnection. As Administrator or root, run the following command:ovet_topoquery getNodeByName SwitchA.hp.com
Running the above command results in the following display:
+++++++++++++++++ NMInterface ++++++++++++++ObjID:31ebc672-f5c1-71d7-11b6-0f0276230000NNMObjID:808EntityName:SwitchA.hp.com[ 0 [ 2 ] ]Description:2::==========Interface Property===============VPI:0VCI:0BoardNo:PortNum:2AuxPortNum:2IfIndex:2IfName:2::
Appendix C 311
Modifying Connections with the Connection EditorUsing the Connection Editor
3. For this example, assume that port 2 is the actual port number usedon SwitchA as displayed in the output from the previous step. Editthe connectionEdits file and add the following statement:
insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘SwitchA.hp.com[ 0 [ 2 ] ]’,’SwitchB.hp.com[ 0 [ 42 ] ]’,1);
Notice that the value for the m_Command field of the insert statementis 1 for add.
Example C-3 Adding Connections for Unsupported Devices
Extended Topology does not yet support all network devices. When anunsupported 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 toan unsupported switch that physically links each of the routers in a starconfiguration. Although the connectivity it provides was discovered, thedevice itself was not, so it is missing from the layout. You will want to usethe connectionEdits file to create a correct topology model.
In Figure C-2 on page 313, the false mesh may be due to an unsupportedswitch that, although it is physically linking each of the routers, it ismissing from the center of the web on your Dynamic View.
Appendix C312
Modifying Connections with the Connection EditorUsing the Connection Editor
Figure C-2 A False Mesh of Connections
In this situation, each of the connections on devices around the edge willbe connected to other devices in the false mesh by the same interface.This means that the ifIndexwill be the same as the other devices in themesh. To remove the false mesh, you may have to insert a deleteconnection entry to the connectionEdits file for each of theseconnections. You will also have to insert an add connection entry in theconnectionEdits file for each of the actual connections from theunsupported device to the switch. Use the following procedure to fix theproblem in this example:
1. To create the delete connection entries, find the ifIndex value foreach device in the false mesh. This is most easily done from aNeighbor View by moving your mouse over each port icon and notingthe Interface Number field located in the popup. For the abovepicture, this would yield entries such as:
Appendix C 313
Modifying Connections with the Connection EditorUsing the Connection Editor
insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’mcrouter81.hp.com[ 0 [ 4 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’mcrouter85.hp.com[ 0 [ 6 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’mcrouter82.hp.com[ 0 [ 5 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’c8kloop.hp.com[ 0 [ 1 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’mcrouter84.hp.com[ 0 [ 7 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter81.hp.com[ 0 [ 4 ] ]’,’mcrouter85.hp.com[ 0 [ 6 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter81.hp.com[ 0 [ 4 ] ]’,’mcrouter82.hp.com[ 0 [ 5 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter81.hp.com[ 0 [ 4 ] ]’,’c8kloop.hp.com[ 0 [ 1 ] ]’,2);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter81.hp.com[ 0 [ 4 ] ]’,’mcrouter84.hp.com[ 0 [ 7 ] ]’,2);::
2. To create the add connection entries, find the ifIndex value for eachof the interfaces on the unsupported device. This could be done byphysically examining the device, by querying the appropriate SNMPMIB which provides forwarding table information (perhaps using theNNM MIB Application Builder tool), or by some other proprietarymeans.
Once you obtain this connectivity information, create entries in theconnectionEdits file for each of the devices located at the edge ofthe spider web. These entries describe their connections to theunsupported device that is located in the middle of the false mesh.This device is identified as mcswitch in the example below.
insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter83.hp.com[ 0 [ 3 ] ]’,’mcswitch.hp.com[ 0 [ 21 ] ]’,1);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter81.hp.com[ 0 [ 4 ] ]’,’mcswitch.hp.com[ 0 [ 22 ] ]’,1);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter82.hp.com[ 0 [ 5 ] ]’,’mcswitch.hp.com[ 0 [ 23 ] ]’,1);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter84.hp.com[ 0 [ 7 ] ]’,’mcswitch.hp.com[ 0 [ 24 ] ]’,1);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘c8kloop.hp.com[ 0 [ 1 ] ]’,’mcswitch.hp.com[ 0 [ 25 ] ]’,1);insert into disco.connectionEdits (m_Name,m_NbrName,m_Command) values(‘mcrouter85.hp.com[ 0 [ 6 ] ]’,’mcswitch.hp.com[ 0 [ 26 ] ]’,1);
Appendix C314
Modifying Connections with the Connection EditorUsing the Connection Editor
An Extended Topology discovery using the above additions to theconnectionEdits file would result in the Neighbor View shown inFigure C-3.
Figure C-3 Corrected Neighbor View
Other Limitations and Behaviors
• Interfaces described in the connectionEdits file must physicallyexist. Extended Topology must be able to discover these interfaces.
• If you create a connection for an interface in the connectonEditsfile, that does not prevent Extended Topology from creating otherconnections to that interface.
Appendix C 315
Modifying Connections with the Connection EditorUsing the Connection Editor
• If you used the ovet_topoconnedit.ovpl script to make changes tothe extended topology database and want to see the changes youmade to the connectionEdits file reflected in dynamic views, youmust restart the OpenView application server (ovas) and the ActiveProblem Analyzer (referred to as APA or the ovet_poll process):
1. As Administrator or root, type ovstop ovas.
2. Press Return or Enter.
3. As Administrator or root, type ovstop ovet_poll.
4. Press Return or Enter.
5. As Administrator or root, type ovstart ovas.
6. Press Return or Enter.
7. As Administrator or root, type ovstart ovet_poll.
8. Press Return or Enter.
• To make sure the Dynamic Views contain all of your changes, youshould initiate a new discovery each time you make changes to theconnectionEdits file.
NOTE A new discovery ensures that all extended topology data is consistentwith the changes introduced in the connectionEdit file.
Appendix C316
D Controlling Log Files
All default logging for installed OpenView components is controlled by aconfiguration file, log.cfg. This file sets the system-wide defaults forcommon logging.
Appendix D 317
Controlling Log FilesTypes of Log File
Types of Log FileThere are two types of log file - binary and text. By default, all processeswrite to binary log files. These are locale-neutral. Take, for example, abinary file generated in a Japanese system. Using the ovlogdump tool(see ovlogdump(1)), you would see Japanese messages. If you were totake the same log file, install it on an English system, then, using theovlogdump tool, you would see English messages.
Text log files are locale-specific. Messages are written to the text files inthe language set by the local environment variable. Text logging can beswitched off or on (see “Switching Logging Off and On” on page 321).
Appendix D318
Controlling Log FilesControlling the Size of Log Files
Controlling the Size of Log FilesTo prevent log files from growing excessively, log file rolling is used tocreate multiple smaller files that can be archived or removed. You canspecify a maximum number of log files to be created and the maximumsize of each log file. Whenever a log entry causes a log file to exceed themaximum size, the file is closed and a new file is opened, using the nextsequence number as part of its name.
For example, say you had a log file called system.txt. When that file isfull, the file is renamed to system.txt.001 and a new system.txt iscreated. 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 iscreated.
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 noblanks, blank lines, or comments. The keywords are case-sensitive.
The keywords are:
BinSizeLimit=n
Sets the maximum size of binary log files to n bytesbefore it rolls to the next file. Default is 10000.
BinFileLimit=n
Sets the maximum number of binary log files togenerate before throwing away log entries. Default is10.
TextSizeLimit=n
Sets the maximum size of text log files to n bytes beforeit rolls to the next file. Default is 10000.
TextFileLimit=n
Sets the maximum number of text log files to generatebefore throwing away log entries. Default is 10.
Appendix D 319
Controlling Log FilesControlling the Size of Log Files
The configuration and log files for MS Windows systems are stored in thefollowing locations indicated in Table D-1.
The configuration and log files for UNIX systems are stored in thefollowing locations indicated in Table D-2.
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
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
Appendix D320
Controlling Log FilesSwitching Logging Off and On
Switching Logging Off and OnYou can switch logging off and on by changing the settings in the loggingconfiguration file, log.cfg.
The file contains a keyword and value pair per line. There can be noblanks, 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 alocale-specific log in human-readable format. Default isoff.
OVLog=off|on
Switches binary logging off and on. Default is on.
WARNING Switching off this option will prevent any binarylogging 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 OpenViewOperations event system off or on. Default is on.
See Table D-1 and Table D-2 for more information about the location ofthe configuration and log files on UNIX and MS Windows systems.
Appendix D 321
Controlling Log FilesSwitching Logging Off and On
Appendix D322
Glossary
A
ABR Area Border Router. A router with aninterface in more than one OSPF area.
Area OSPF divides contiguous networksand hosts into a number of areas using AreaBorder Routers.
ARP Address Resolution Protocol. Aprotocol that maps IP addresses to Ethernetaddresses.
ATM Asynchronous Transfer Mode. Ahigh-speed connection-oriented switchingtechnology that uses 53-byte cells (packets)to simultaneously transmit different types ofdata, including video and voice.
C
Community String A plain text passwordused to authenticate SNMP queries toSNMP agents.
D
Dual Stack A router or host that isconfigured for both IPv4 and IPv6.
Dynamic Views Describes the family ofbrowser-based views whose content iscreated as a result of choices you make whenyou launch the view, and which continue toprovide the most current status informationavailable.
H
Home Base The main launching point forDynamic Views.
HSRP Hot Standby Routing Protocol. Aproprietary Cisco protocol that providesbackup to a router when it fails.
I
ILMI Interim Local Management Interface.An independent industry standard used forconfiguring ATM interfaces.
IPv4-Compatible Addresses Dual-stackednodes understand both IPv4 and IPv6addresses and use IPv4-compatibleaddresses to tunnel IPv6 packets throughIPv4 routers. Ipv4-compatible addresseshave their 96 high-order bits set to zero and32 low-order bits set to an IPv4 address.Using this technique, dual-stacked nodescan use the same address for IPv4 and IPv6packets.
IPv6 Global-Scoped Addresses Theseaddresses, normally referred to asaggregatable global unicast addresses, referto IPv6 addresses that begin with 001. Atsome future time, IPv6 global-scopedaddresses may include other currentlyunassigned unicast IPv6 prefixes.
IPv6 Link-Local Scoped Addresses
These addresses are only used to connectneighboring nodes. Link-local addressesalways have the prefix 1111 1110 10 in thefirst ten bits. Almost all IPv6 addresses willhave a link-local address.
IPv6 Prefix Group A prefix group issimilar to a subnet in IPv4. A prefix grouphas a specific scope: site-local scopedaddresses or global-scoped addresses. Thereare no prefix groups for link-local scopedaddresses.
Glossary 323
Glossary
IPv6 Site-Local Scoped AddressesIPv6 Site-Local Scoped Addresses Theseaddresses can only be used within anisolated internet. Site-local scoped addressesalways have the prefix 1111 1110 11 in thefirst ten bits.
M
MIB Management Information Base. In thecontext of managed devices, a collection ofobjects that can be accessed via a networkmanagement protocol.
N
Neighbors Two devices that have directlyconnected interfaces.
O
OAD Overlapping Address Domains. TheOAD denotes a set of unique, private IPaddresses. The OAD view is useful whenmonitoring several OADs that containoverlapping private IP addresses.
OSI Model Open Systems InterconnectModel. A network design frameworkestablished by the ISO (InternationalStandards Organization) to provideequipment from different vendors to be ableto communicate.
OSPF Open Shortest Path First protocol. Aprotocol that routers use to communicatebetween themselves. OSPF has the ability toconfigure topologies and adapt to changes inthe Internet.
P
Port Aggregation A method of connectingtwo Ethernet switches with two or morecables.
S
SNMP Simple Network ManagementProtocol. A standard protocol used tomanage TCP/IP networks.
T
Threshold A preset, calculated, or MIBinstance value used in NNM data collection.NNM can generate an alarm when athreshold violation occurs.
Tunneling Enabling networkcommunication between two IPv6 networksby forwarding IPv6 packets across an IPv4network.
V
VCI Virtual Channel Identifier. The addressor label of an ATM Virtual Circuit.
VLAN Virtual LAN. The creation of multiplelogical networks within a single physicalnetwork or switching device. Each VLANcreates a new broadcast domain.
VPI Virtual Path Identifier. The address ofan ATM virtual path.
Glossary324
Index
AActive Problem Analyzer
see APA, 86Advanced Routing SPI, 86, 238
discoveringHSRP information, 238IPv6 information, 239OSPF information, 238
discoveryIPv6, 240IPv6 configuration files, 240
HSRPdiscovery, 257
IPv6configuration files, 240discovery, 240IPv6 Global Network view, 244Prefix Groups, 245references, 264Site-Local Network view, 248troubleshooting discovery, 242
IPv6 Global Network view, 244OSPF
discovery procedure, 252references, 264troubleshooting discovery, 253
OSPF viewtroubleshooting with, 254
advantages of using APA, 89, 90Agent MSI, 164, 168aggregated port
about term, 198correlating events, 227
alarmsAPA Address Down, 199, 206APA Address Intermittent, 199, 206APA Address Up, 206APA Aggregated Port, 202, 227APA Board Down, 200, 216APA Connection Down, 199, 207, 210, 224APA Connection Intermittent, 199, 207APA Connection Unreachable, 199, 210, 224APA Connection UP, 201, 224APA Connection Up, 207APA Demand Analysis, 201, 220APA Interface Down, 199, 201, 205, 224APA Interface Intermittent, 199, 205APA Interface Unreachable, 224APA Interface Up, 224
APA Node Down, 198, 199, 204, 209APA Node Intermittent, 198, 204APA Node Renumbering, 226APA Node Up, 204, 226OV_HSRP, 225OV_HSRP State Change, 202OV_Link_Down, 209OV_Link_Intermittent, 198, 203
APA, 86, 127adjusting polling engine threads, 117adjusting polling parameters, 112
paConfig.xml file, 112adjusting status analyzer threads, 116advantages, 89, 90alarm reduction, 102alarms
Address Down, 199, 206Address Intermittent, 199, 206Address Up, 206Aggregated Port, 202, 227Board Down, 200, 216Connection Down, 199, 207, 210, 224Connection Intermittent, 199, 207Connection Unreachable, 199, 210, 224Connection Up, 201, 207, 224defined, 102Demand Analysis, 201, 220HSRP, 202Interface Down, 199, 201, 205, 224Interface Intermittent, 199, 205Interface Unreachable, 224Interface Up, 224Node Down, 198, 199, 204, 209Node Intermittent, 198, 204Node Renumbering, 226Node Up, 204, 226
changing default polling interval, 113changing device class polling interval, 114compared to netmon, 91configuring, 110Connector Down correlation, 105cooperation with netmon, 89, 93default polling configuration, 87described, 86disable
using ovet_apaConfig.ovpl script, 109disable from polling specific nodes, 138disable HSRP group polling, 127disable ICMP polling
325
Index
for various ifTypes, 135of specific addresses, 142
disabling correlators, 232do not enable on management stations, 89Dynamic Views status, 100ECS correlations, 105emitting alarms for important nodes, 118enable, 109
paConfig.xml file, 109using ovet_apaConfig.ovpl script, 109
enable HSRP group polling, 127enable on collection stations, 89event reduction, 102existing filters, 121failure analysis, 94FAQ, 146forwarding status information, 93general IPv4 interfaces, 89, 109HSRP group polling
disabling, 128enabling, 128
HSRP monitoring, 86HSRP status, 100ICMP polling
disabling, 131enabling, 131
important nodes, 118netmon device discovery, 89no IPX support, 101node status, 101OAD (Overlapping Address Domain), 86OAD monitoring, 86OV_PollerIntermittent correlators, 104ovet_poll process, 92, 102, 127
starting and stopping, 114, 115, 117, 118,124, 128, 129, 131
Pair Wise correlation, 105Polling Engine, 112, 127polling statistics, 110
Active Analyzer Tasks, 110Addresses Polled, 111Boards Polled, 111HSRP Groups Polled, 111Interfaces Polled, 111Waiting Analyzer Tasks, 111Waiting Poller Tasks, 110
SNMP pollingdisabling, 130enabling, 130
Status Analyzer, 112, 127Status Bridge, 113, 127suppress or allow APA status polling, 125Talker, 112trigger poll correlators, 219unconnected switch ports
disable SNMP polling, 133enable SNMP polling, 133
using topology filters, 120APA Address Down alarm
correlating, 199generating flapping event, 206
APA Address Intermittent alarm, 199, 206APA Address Up alarm
generating flapping event, 206APA Aggregated Port alarm
correlating with LinkDown, 202, 227correlating with syslog, 202generating, 229nesting secondary events, 229
APA Board Down alarm, 200, 216APA Connection Down alarm
correlating with LinkDown, 199, 210correlating with OSPF, 224generating flapping event, 199, 207
APA Connection Intermittent alarm, 199, 207APA Connection Unreachable alarm
correlating with LinkDown, 199, 210correlating with OSPF, 224
APA Connection Up alarmcorrelating with OSPF, 201, 224generating flapping event, 207
APA correlators. See correlatorsAPA Demand Analysis alarm
about, 201generating, 220
APA HSRP alarm, 225APA Interface Down alarm, 199
correlating with OSPF, 201, 224generating flapping event, 205
APA Interface Intermittent alarmgenerating flapping event, 199, 205
APA Interface Unreachable alarmcorrelating with OSPF, 224
APA Interface Up alarmcorrelating with OSPF, 224
APA Node Down alarm, 209correlating LinkDown, 199generating flapping event, 198, 199, 204
APA Node Intermittent alarm
326
Index
generating flapping event, 198, 204APA Node Renumbering alarm, 226APA Node Up alarm, 226
generating flapping event, 204APA poll
configuration request, 219force request, 219issuing request, 220status request, 219Up/Down request, 219
ApplicationOVO template condition field, 187
Automatic Zone Discovery, 23
Bboard
about term, 198Board Down
correlating with APA Board Down, 216correlating with syslog Board Down, 214syslog messages, 216
Board Down event, 200, 212, 216bridge.noDiscover file, 32brownout events, 58, 69brownout parameters
BROWNOUT_BAD_SAMPLES, 70BROWNOUT_INTERVAL, 69BROWNOUT_NUM_ DEVIATIONS, 70BROWNOUT_NUM_SAMPLES, 70BUCKET_SIZE, 70
BROWNOUT_BAD_SAMPLES, 70BROWNOUT_INTERVAL, 69BROWNOUT_NUM_ DEVIATIONS, 70BROWNOUT_NUM_SAMPLES, 70browser
configuring path in ovweb.conf file, 15BUCKET_SIZE, 70
Ccard. See boardCold Start event, 202, 225Cold Start events
listening for, 226command
ovstart, 36ovstatus -v ovet_disco, 277xnmevents, 272
Composerdeploying correlators, 231, 233disabling correlators, 232
editing namespace file, 233factstore files, 233related documentation, 235removing namespaces, 233saving definitions, 231troubleshooting, 235viewing namespaces, 230
Composer correlators. See correlatorsComposer parameters
Count, 203, 204, 205, 206, 208setting, 230Window Period, 203, 204, 205, 207, 208, 210,
211Composer window, 230, 232
Correlator Store pane, 230NameSpace table, 230
Condition Text field, 181configuration options
Syslog Integration, 150configuration poll, 219configuring
Ospf.cfg file, 252ovweb.conf file, 15recurring discovery, 36
connection editor, 302how to use, 304when to use, 299, 302
correlating with Board Down, 214Correlation Composer. See Composercorrelators
about aggregated port events, 202about APA, 198about APA Board Down events, 200about APA poll trigger events, 201about Board Down events, 200about flapping events and APA, 198, 203about LinkDown and APA alarms, 199about NNM, 196about Syslog Integration and APA, 196deploying, 233deploying in Composer, 231, 233description, 196detecting address flapping, 206detecting connection flapping, 207detecting interface flapping, 205detecting multiple LinkDown events, 203detecting node flapping, 204disabling, 232disabling group, 233LinkDown with APA Aggregated Port, 227
327
Index
LinkDown with APA Connection Down, 210LinkDown with APA Node Down, 209namespaces, 198nesting aggregated port events, 227nesting Board Down under APA Board
Down, 216nesting LinkDown under Board Down, 212nesting LinkDown under syslog Board
Down, 213nesting poll trigger events, 201, 224OV_Addr_IntermittentStatus, 206OV_APA_AggregatedPort, 227, 228OV_APA_BoardDown, 217OV_Board_Down, 212OV_Board_Trap_SyslogCorr, 200, 215OV_Connection_IntermittentStatus, 207OV_HSRP_APA, 225OV_HSRP_StateChange, 225OV_Interface_IntermittentStatus, 205OV_Link_Down, 209, 210, 212, 213, 227OV_Link_Down2, 212, 213OV_Link_Intermittent, 203OV_LinkDown_NodeDown, 209OV_Node_IntermittentStatus, 204OV_Node_Restart_Trap, 226OV_NodeRestart_APA, 226OV_NodeRestart_Syslog, 226OV_OSPF_AdjacencyChange, 224OV_OSPF_APA, 224OV_Port_Aggregation, 228OV_Syslog_BoardDown, 217OV_Syslog_LinkDown, 212, 213, 227syslog aggregated port with APA, 228syslog Down with APA Aggregated Port,
227triggering APA poll, 219troubleshooting, 235
Count parameter, 203, 204, 205, 206, 208custom message attributes (CMAs), 188, 189
DDCE requirements, 160DCE RPC, 160DCE-KT-Tools, 160deploy correlators, 233
in Composer, 231, 233deployment options
Syslog Integration, 150devices
supported by Extended Topology, 276disable correlators
using Composer, 232using namespace file, 233
disabling Syslog Integration, 191discovery
editing with connection editor, 302HSRP, 257in Extended Topology, 16, 20
troubleshooting, 277limiting, 32nodes, boards, interfaces, and addresses, 91OSPF, 16, 252single zone, 38unresponsive devices, 34zones, 20, 23
Dynamic Viewsaccessing from NNM Alarm Browser, 17accessing online help, 17APA status, 100ATM information, 14described, 14Extended Topology information
use object’s primary collection station, 22modifying menu items, 18Neighbor view, 14Node view, 14Path view, 14security, 32showing status information, 93VLAN view, 14
dynamicViewsUsers.xml file, 32
EECS
layer 2 and 3 network paths, 274PairWise correlation, 203, 204, 205, 206, 207
ECS Configuration window, 230, 232etrestart.ovpl
-force option, 24manpage, 31, 36script, 24, 28, 29, 31, 37, 38, 278
Event Configuration window, 230, 232events
Board Down, 200, 212, 216Cold Start, 202, 225correlating flapping with APA, 203HSRP State Change, 202, 225LinkDown, 198, 199, 200, 202, 212, 213
328
Index
OSPF Adjacency Change, 201, 224PAGP_JoinedBridgePort, 229PAGP_LeftBridgePort, 229syslog aggregated port, 228Warm Start, 202, 225
Extended Topologyaccessing NNM Release Notes, 18accessing online help, 18accessing this manual, 18backing up configuration files, 276checking for latest patches, 276configuring recurring discovery, 36connection editor, 302deployment tips, 294differs from extended topology, 88discovery, 16, 20
basics, 20configuring, 36limiting, 32nodes, boards, interfaces, and addresses,
91recurring, 36status of, 33troubleshooting, 277unresponsive devices, 34zones, 20, 23
Discovery Exclusion List, 32discovery tips, 296editing connections, 302information discovered by, 21
board and port information, 21layer 2 information, 21port aggregation, 21VLAN information, 21
introducing, 14NNM and Extended Topology, 14post discovery tips, 298prediscovery tips, 294recurring discovery
configuring, 34supported
devices, 276JPI versions, 15web browser, 15
troubleshootingdiscovery, 277views, 280
use object’s primary collection station, 22using SNMP community strings, 30, 31
extended topologydiffers from Extended Topology, 88
Extended Topology Discovery, 23
Ffactstore files
location, 233FAQ, 146file
bridge.noDiscover, 32dynamicViewsUsers.xml, 32IPv6.conf, 240IPv6Polling.conf, 240IPv6Prefix.conf, 240IPv6Scope.conf, 240, 241IPv6Seed.conf, 240Ospf.cfg, 252ovweb.conf, 16xnmeventsExt.conf, 272
flapping eventscorrelating address up/down, 206correlating connection up/down, 207correlating interface up/down, 205correlating node up/down, 204correlators, 203
force poll, 219triggering request, 219
Ggeneral IPv4 interfaces, 89
polling, 90
HHome Base, 16
accessing, 16checking discovery status, 33definition, 16described, 16URL, 16
hosts.nnm file, 89, 101, 109HSRP
correct handling of virtual IP addresses,257
discovery, 257validating results, 259
group status information, 260HSRP group polling
disabling, 127enabling, 127
329
Index
HSRP pollingdisabling, 128enabling, 128
HSRP State Change event, 202, 225HSRP State Change events
listening for, 225viewing suppressed, 225
IICMP polling
disabling, 131enabling, 131
important nodes, 118IPv6
events, 250understanding status information, 248
JJPI versions
supported, 15
LLinkDown event, 198, 199, 200, 202, 212, 213LinkDown events
correlating repeated, 203correlating with APA Aggregated Port, 227correlating with APA Connection Down, 210viewing suppressed, 228viewing suppressed in browser, 214
log filescontrolling, 317switching on and off, 321
logfilesyslog.log, 192
logger, 162, 166, 170
Mmanpage
bridge.noDiscover, 32etrestart.ovpl, 31, 36ovsnmp.conf_db, 30ovstart, 36ovweb.conf, 15setupExtTopo.ovpl, 30, 36xnmsnmpconf, 31
Message GroupOVO template condition field, 187
Message on Matched ConditionOVO template condition field, 187
message source templatesoverview, 173
Message Source Templates interface, 155,164, 168, 174
assigning templates, 165, 169installing templates, 165, 169
Message Source Templates windowstarting, 176
message stream interfacetroubleshooting, 192
message stream interface (MSI), 164, 168Message Text
OVO template condition field, 186, 188Message Type
OVO template condition field, 188message type
NNMsyslog_, 151, 188module. See boardModuleDown event. See Board Down eventMSI
enabling OVO agent, 164, 169enabling template, 164, 168
Nnamespace file
location, 233NameSpace.conf file, 233namespaces
OV_CiscoBoard, 200, 212OV_PollerBoardDown, 200, 216OV_PollerIntermittent, 198, 203OV_PollerLinkDown, 199, 209OV_PollerPortAgg, 202, 227OV_PollerTrigger, 201, 219OV_PollerTriggerCorr, 201, 224removing from Composer, 233
Neighbor viewaccessing, 16and board/port information, 268and port aggregation, 267troubleshooting with, 266, 269, 270
netmondevice discovery for APA, 89
netpath_http/etc/services entry, 71
NISsyslog requirement, 161
NNMenvironment variables, 15Extended Topology and NNM, 14
330
Index
Release Notes, 18starting, 183universal path names, 15
NNM Advanced Edition, 14NNM standalone configuration
configuring syslog monitoring, 155deploying, 156deploying templates, 190describing Syslog Integration, 151disabling, 171setting up, 155, 162testing, 162
NNM Syslog Trap Mapping ConfigurationInterface
about, 153NNMsyslog_ message type, 151, 188NNMsyslogTraps, 164, 167Node
OVO template condition field, 185, 187Node view
accessing, 16npprobe.conf file, 67, 71
OOAD, 86
see Overlapping Address Domain, 42Object
OVO template condition field, 187online help
accessing from Dynamic Views, 17opc
starting OVO, 155opc command
starting OVO, 176opc_op
add OVO user locally, 161opccfgupld, 164, 168opcpat, 190opctemplate, 193OSPF
configuring Ospf.cfg file, 252correlating Adjacency events, 224discovery, 16ospfdis.err file, 252ospfdis.ovpl script, 252suggested reference material, 253supported MIBs, 252
OSPF Adjacency Change event, 201, 224OSPF Adjacency events
viewing suppressed, 225
OV_Addr_IntermittentStatus correlatorbehavior, 206setting parameters, 206
OV_APA_ADDR_DOWN. See APA AddressDown alarm
OV_APA_ADDR_Intermittent. See APAAddress Intermittent alarm
OV_APA_ADDR_UP. See APA Address Upalarm
OV_APA_AggregatedPort correlatorbehavior, 227, 228
OV_APA_BoardDown correlatorbehavior, 217
OV_APA_CONN_Intermittent. See APAConenction Intermittent alarm
OV_APA_CONNECTION_DOWN. See APAConnection Down alarm
OV_APA_CONNECTION_UNREACHABLE. See APA Connection Unreachable alarm
OV_APA_CONNECTION_UP. See APAConnection Up alarm
OV_APA_IF_DOWN. See APA InterfaceDown alarm
OV_APA_IF_Intermittent. See APA InterfaceIntermittent alarm
OV_APA_IF_UNREACHABLE. See APAInterface Unreachable alarm
OV_APA_IF_UP. See APA Interface Upalarm
OV_APA_NODE_DOWN. See APA NodeDown alarm
OV_APA_NODE_Intermittent. See APANode Intermittent alarm
OV_APA_NODE_UP. See APA Node Upalarm
OV_Board_Down correlatorbehavior, 212
OV_Board_Trap_SyslogCorr correlatorabout, 200behavior, 215
OV_CiscoBoard namespaceabout, 200, 212
OV_Connection_IntermittentStatuscorrelator, 207
setting parameters, 208OV_HSRP
generating alarm, 225State Change alarms, 225
OV_HSRP state change alarm, 202OV_HSRP_APA correlator
behavior, 225OV_HSRP_StateChange correlator
331
Index
behavior, 225OV_Interface_IntermittentStatus correlator
behavior, 205setting parameters, 205
OV_Link_Down alarm, 209OV_Link_Down correlator, 210
behavior, 209, 212, 213, 227setting parameters, 210
OV_Link_Down2 correlatorbehavior, 212, 213
OV_Link_Intermittent alarm, 198, 203OV_Link_Intermittent correlator
behavior, 203OV_LinkDown_ConnDown correlator
behavior, 210setting parameters, 211
OV_LinkDown_NodeDown correlatorbehavior, 209setting parameters, 210
OV_Node_IntermittentStatus correlatorbehavior, 204setting parameters, 204
OV_Node_Restart_Trap correlatorbehavior, 226
OV_NodeRestart_APA correlatorbehavior, 226
OV_NodeRestart_Syslog correlatorBehavior, 226
OV_OSPF_AdjacencyChange correlatorbehavior, 224
OV_OSPF_APA correlatorbehavior, 224
OV_PollerBoardDown namespaceabout, 200, 216
OV_PollerIntermittent correlators, 104OV_PollerIntermittent namespace
about, 198, 203OV_PollerLinkDown namespace
about, 199, 209OV_PollerPortAgg namespace
about, 202, 227OV_PollerTrigger namespace
about, 201, 219OV_PollerTriggerCorr namespace
about, 201, 224OV_Port_Aggregation correlators
behavior, 228OV_Syslog_BoardDown correlator
behavior, 217OV_Syslog_FrameDLCI_Active, 157OV_Syslog_FrameDLCI_Inactive, 157
OV_Syslog_LineProtoDown, 157OV_Syslog_LineProtoUp, 157OV_Syslog_LinkDown, 157OV_Syslog_LinkDown correlator
behavior, 212, 213, 227OV_Syslog_LinkUp, 157OV_Syslog_OSPF_Neighbor_Down, 157OV_Syslog_OSPF_Neighbor_Up, 157Overlapping Address Domain, 22
and undiscovered NAT devices, 48configuring discovery, 43configuring SNMP data collection, 53defined, 42deleting a single zone, 46discovery, 46see OAD, 86understanding status, 53undiscovered NAT devices
remedy with NextHop keyword, 50ovet_apaConfig.ovpl script, 109ovet_poll process, 92, 102, 127
starting and stopping, 114, 115, 117, 118,124, 128, 129, 131
ovet_topodump.ovpl script, 120, 121ovet_toposet command, 125OVO agent
in NNM standalone configuration, 155, 173in Syslog Integration
NNM Standalone configuration, 151OVO with NNM configuration, 153
OVO serverin OVO with NNM configuration, 153
OVO template condition fieldMessage Group, 187Message Text, 188Message Type, 188Node, 187Service Name, 188
OVO templatestroubleshooting, 193
OVO with NNM configurationdescribed, 153disabling, 171setting up, 156, 163, 167testing, 166, 170
ovsnmp.conf_dbmanpage, 30
ovstartcommand, 36manpage, 36
332
Index
ovstart command, 73ovstatus -v ovet_disco command, 277ovstop command, 73ovsyslogcfg, 155, 162, 174ovtrap2opc, 166, 170
in OVO with NNM configuration, 154ovweb.conf
file, 16manpage, 15
ovweb.conf filechanging browser location path, 15
PpaConfig.xml file, 109, 112, 120PAGP_JoinedBridgePort event, 229PAGP_LeftBridgePort event, 229parameters
Count, 203, 204, 205, 206, 208setting, 230Window Period, 203, 204, 205, 207, 208, 210,
211Path view
accessing, 16pdcentral.sh command, 74, 83pdconfig.xml, 69, 71pdconfig.xml file, 64, 65, 69, 71pdpinstall.sh command, 61pdpinstall.vbs command, 63pmd
in OVO with NNM configuration, 154pmd process
describing roleSyslog Integration, 152
pollissuing request, 220trigger configuration request, 219
poll triggering eventscorrelating, 224
Polling Engine, 127Probes
configuring targets, 72probes
about, 57changing port, 71checking status, 83installing on HP-UX, 61installing on Solaris, 62installing on Windows, 63installing remote, 60linking server to, 67linking to server, 65
running standalone, 77starting, 73stopping, 74
Problem Diagnosis, 56changing ports, 70configuring brownouts, 69configuring probe targets, 72configuring probes, 72configuring server port, 71database, 82probes, 57, 60server, 56starting probe, 73starting server, 73stopping server, 73view, 56, 59, 72
Problem Diagnosis databasefixing a corrupt, 82
Problem Diagnosis probesabout, 57changing port, 71checking status, 83configuring, 67standalone mode, 77starting, 73, 74stopping, 74
Problem Diagnosis serverabout, 56changing port, 71checking status, 83configuring, 64configuring probes, 65starting, 73stopping, 73
publicationsCorrelation Composer’s Guide, 196, 235Managing Your Network, 196
RRAMS (Route Analytics Management
System), 238recurring discovery
configuring in Extended Topology, 34Release Notes
accessing, 18RELOAD
syslog message, 226RESTART
syslog messages, 226
333
Index
Sscript
etrestart.ovpl, 24, 28, 29, 31, 37, 38, 278ospfdis.ovpl, 252setupExtTopo.ovpl, 36
Service NameOVO template condition field, 188
setupExtTopo.ovplmanpage, 30, 36script, 30, 36
setupSyslog.ovpl, 155-deploy option, 156, 190-disable option, 171, 190-help option, 155-server option, 156, 163, 167-standalone option, 155, 162
setupSyslog.ovpl command-disable option, 191
Site-Local Network view, 248SNMP community strings
used by Extended Topology, 30, 31SNMP polling
disabling, 130enabling, 130
SNMP Traps template, 166, 170Status Analyzer, 127Status Bridge, 127status poll, 219supported devices
obtaining information about, 276Suppress Matched Condition
OVO template condition field, 186Suppress Unmatched Condition
OVO template condition field, 186syslog
correlating Down events with APAAggregated Port, 227
syslog aggregated port event, 228syslog Board Down events
correlating with Board Down, 214correlating with syslog Down events, 213
Syslog FRAME DLCI Active, 179Syslog FRAME DLCI Inactive, 179Syslog FRAME DLCI Invalid, 179Syslog Integration
and APA correlators, 196configuring, 162, 163, 167deployment options
describing, 150NNM standalone, 151
describing, 150disabling, 190
in NNM Standalone configuration, 190in OVO with NNM configuration, 191
logfilesyslog.log, 192
OVO agentin NNM standalone configuration, 151in OVO with NNM configuration, 153
OVO with NNM configurationdescribing, 153
pmd process, 152removing, 171starting syslog process, 191stoppping syslog process, 191system logfile, 192template
Syslog to NNM, 177troubleshooting
duplicate messages in browser, 192not seeing messages in browser, 193
Syslog LINEPROTO down, 179Syslog LINEPROTO up, 179Syslog LINKDOWN, 179Syslog LINKUP, 179syslog logfile
location, 192syslog message
Link Downviewing suppressed in browser, 214
syslog messagesaggregated port
correlating with APA alarm, 202, 228Board Down, 214
correlating beneath, 200, 212correlating with APA Board Down, 216
correlating with syslog Board Down, 213generating OV_Syslog_ alarms, 151Line Protocol Down
correlating with APA Aggregated Port,227
correlating with Board Down, 212correlating with syslog Board Down, 200,
213viewing suppresed in browser, 214
Link Downcorrelating with APA Aggregated Port,
227correlating with Board Down, 212
334
Index
correlating with syslog Board Down, 200,213
RELOAD, 202, 225RESTART, 202, 225, 226seeing duplicate in browser, 192viewing suppressed, 228viewing suppressed aggregated port, 229
Syslog OSPF Adjacency down, 179Syslog OSPF Adjacency up, 179Syslog to NNM template, 153, 154, 155, 173
assigning to agent, 165, 169Condition Text field, 181deploying, 190describing, 177in NNM standalone configuration, 181in OVO with NNM configuration, 184syslog trap mappings, 156uploading in OVO with NNM configuration,
164, 168Syslog Trap Mapping Configuration
interface, 174starting, 155
syslog.log file, 192syslogTrap
in NNM standalone configuration, 155in OVO with NNM configuration, 154starting in OVO with NNM configuration,
166, 170syslogTrap process
in NNM standalone configuration, 151starting in OVO with NNM configuration,
191stopping in NNM standalone configuration,
190stopping in OVO with NNM configuration,
191
TTalker, 127template condition
testing syntax, 190templates
deploying in NNM standalone, 190verifying installed, 193
testing configuration, 162trap OID, 182trapd.conf, 153troubleshooting
Composer, 235syslog messages, 192, 193
trunk. See aggregated port
Uunconnected switch ports
disable SNMP polling, 133enable SNMP polling, 133
Vview
Problem Diagnosis, 56, 59, 72views
see Dynamic Views, 14VLAN view
accessing, 16troubleshooting with, 268, 270
WWarm Start event, 202, 225Warm Start events
listening for, 226web browsers
supported, 15window
Composer, 230, 232ECS Configuration, 230, 232Event Configuration, 230, 232Message Source Templates, 176NNM Syslog Mapping Configuration, 153Problem Diagnosis Configuration, 72Status Alarms Browser, 225, 226, 228
Window Period parameter, 203, 204, 205, 207,208, 210, 211
Xxnmevents
command, 272xnmeventsExt.conf file
launching view and URLs, 272modifying, 272
xnmsnmpconfmanpage, 31
ZZone-based Configuration
automatic, 24manual, 26
Zone-based Discovery, 23automatic zone discovery, 23
335