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

http://openview.hp.com

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


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


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


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


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


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


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


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


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].


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


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].


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].


Chapter 226


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


*.* 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


Chapter 228


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


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


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:



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


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


• 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


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


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


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


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


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.



3. Select [Initiate Full Discovery Now]

• If you add new devices to a specific zone, complete the followingprocedure:

1. Go to Home Base



4. Select the [Discovery Zones] tab

5. Select the zone you modified

6. Select [Discover Zone]

NOTE The [Discover Zones] button causes Extended Topology to run a 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


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:



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


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


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


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


• 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


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


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].



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


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


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


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


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


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


egressdevice

Unknown

NAT

OAD 0OAD 7

Chapter 3 51


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


NormalMinor

CriticalUnknownNot Discovered

NAT

Interface 1Down

Normal Area

FaultArea

FaultArea OAD 7

OAD 0

Chapter 352


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


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


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


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


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


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


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.


Table 4-2 Instructions for Installing Remote Probes (Continued)


Instructions

Chapter 462


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.


Table 4-2 Instructions for Installing Remote Probes (Continued)


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


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:


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


<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>


</PROBE>

The resulting file looks like this:

<?xml version= "1.0" encoding=”UTF-8” ?>

<PD_CONFIG>

<PROBELIST>

<PROBE>

<HOST_NAME> Icarus.naucrates.com </HOST_NAME>


</PROBE>

<PROBE>

<HOST_NAME> Daedalus.naucrates.com </HOST_NAME>

<IP_ADDERSS> 15.2.116.72</IP_ADDRESS>

</PROBE>

</PROBELIST>

</PD_CONFIG>

Chapter 466


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


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


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:


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


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


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


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


• 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


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


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


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


• 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


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


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


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


• 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


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


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


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


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.



Chapter 592


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.



Chapter 5 93


— 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


• 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


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


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


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


• 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


• 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


• 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


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


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


<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.


• Windows: %OV_BIN%\ovstop -c ovet_poll

Chapter 5 107


• UNIX: $OV_BIN/ovstop -c ovet_poll


• Windows: %OV_BIN%\ovstart -c ovet_poll

• UNIX: $OV_BIN/ovstart -c ovet_poll

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


— 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


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


<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:


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


3. Look for the following polling interval text:

<classSpecificParameters>



<defaultParameters>

Chapter 5 113


<parameterList>

<parameter>


<title>Interval to Poll Device</title>

<description>

The interval which the device will be polled in seconds.

</description>

<varValue>


<value>300</value>

</varValue>

</parameter>

Change the bold number to the number of seconds you want APA towait before again polling devices that do not belong to any defineddevice class. Make sure to save your changes.







This applies your changes to the APA polling process.

Changing the Polling Interval by Device Class

The paConfig.xml file references filters that allow you to modify 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:


Chapter 5114




3. Look for the isRouter filter text that looks as follows:

<classSpecification>

<filterName>isRouter</filterName>

<parameterList>

<parameter>



<description>


</description>

<varValue>


<value>300</value>

</varValue>

</parameter>

Modify the bold number to the number of seconds you want APA towait before repolling devices that pass the isRouter filter. Makesure to save your changes.







This applies your changes to the APA polling process.

Chapter 5 115


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:




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


</description>

<varValue>


<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.







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:




3. Look for the following polling engine thread pool text:

<parameter>

Chapter 5 117


<name>PollingEngineThreadPoolSize</name>

<title>Polling Engine Thread Pool Size</title>

<description>

This parameter specifies how many threads are in the polling

engine thread pool. Increasing the value of this parameter,

increases the amount of pooling parallelism and the amount of

system resources consumed (e.g. number of file descriptors).

Increasing the value of this parameter may or may not increase

polling engine performance.

</description>

<varValue>


<value>16</value>

</varValue>

</parameter>

Change the bold number to the number of threads you want in thepolling engine thread pool. Make sure to save your changes.







Configuring APA to Display Alarms from Important Nodes

APA does not emit failure alarms for devices that are located in 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


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 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>



<description>


</description>

<varValue>


<value>300</value>

</varValue>

</parameter>

Chapter 5120


<parameter>

<name>snmpEnable</name>

<title>Enable polling via SNMP</title>

<description>

Enable/Disable polling of a device via SNMP.

</description>

<varValue>


<value>true</value>

</varValue>

</parameter>

You can use extended topology filters to add device classes into 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


ConnectedIFInInfrDevConnectedNodeExceptionInfrDevExceptionNodeExtremeDevicesHasBoardsHSRPCoreGroupIFConnectedToEndNodeIfTypeFilterImportantNodesInfrDevInterfaceInEndNodeInterfaceInInfraDevInterfaceInRouterInterfaceInSwitchInterfaceWithMPLSNameInterfacesWithAnycastAddrsInterfacesWithDupAddrsNoPingAddressesNodeWithDownInterfaceNodeWithMPLSIdNodesWithBoardsNodesWithRhinoMIBNodesWithStackMIBNonSnmpNodeNonSnmpSwitchNortelDevicesNotConnectedIFNotConnectedNodeNotConnectedSnmpRouterNotConnectedSnmpSwitchProcurveDevicesRHINOMIBSTACKMIBSnmpEndNodeSysNameThreeComDevicesTrunkPortUnconnectedAdminDownRouterIFUnconnectedAdminDownSwitchIFUnconnectedAdminUpOrTestRouterIFUnconnectedAdminUpOrTestSwitchIFUnconnectedEndNodeWanIFisATMisCDP

Chapter 5122


isEndNodeisFrameRelayisHSRPisIpPhoneisPartOfAggregatedIFisRouterisSnmpisSwitchslowIfSpeedsvlanTrunkPortwanIfTypes

2. Run the ovet_topodump.ovpl -node -filt ProcurveDevicescommand to get a list of all of the ProCurve devices in yourenvironment.



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>



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.


<filterName>ProcurveDevices</filterName>

<parameterList>

<parameter>

Chapter 5 123




<description>


</description>

<varValue>


<value>300</value>

</varValue>

</parameter>

<parameter>



<description>


</description>

<varValue>


<value>true</value>

</varValue>

</parameter>

</parameterList>

</classSpecification>

Make sure to save your changes.






Chapter 5124



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


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:




3. Look for the following HSRP group polling enabling text:

<parameter>

<name>HSRPPollingEnable</name>

<title>Enable HSRP Polling</title>

<description>

Chapter 5 127


Enable/Disable polling of HSRP Groups.

</description>

<varValue>


<value>true</value>

</varValue>

</parameter>

Modify the bold true to false if you want to disable the global HSRPpolling or true if you want to enable the global HSRP polling. Makesure to save your changes.







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:




3. Look for the following HSRP group polling enabling text:

Chapter 5128


<parameter>

<name>hsrpEnable</name>


<description>

Enable/Disable polling of HSRP Group. If the router/interface

does not have hsrp enabled then setting this parameter to

true does nothing.

</description>

<varValue>


<value>true</value>

</varValue>

</parameter>

Modify the bold true to false if you want to disable HSRP polling ortrue if you want to enable HSRP polling. This parameter enables ordisables HSRP polling for routers, ports, and interfaces. Make sure tosave your changes.







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


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:




3. Look for the following SNMP polling enabling text:



<defaultParameters>

<parameterList>

<parameter>



<description>


</description>

<varValue>


<value>300</value>

</varValue>

</parameter>

<parameter>


Chapter 5130



<description>


</description>

<varValue>


<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.







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:



Chapter 5 131


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:



<defaultParameters>

<parameterList>

<parameter>



<description>


</description>

<varValue>


<value>300</value>

</varValue>

</parameter>

<parameter>



<description>


</description>

<varValue>


<value>true</value>

</varValue>

</parameter>

<parameter>

Chapter 5132


<name>pingEnable</name>

<title>Enable polling via ICMP</title>

<description>

Enable/Disable polling of a device via ICMP.

</description>

<varValue>


<value>true</value>

</varValue>

</parameter>

Modify the bold true to false if you want to disable ICMP polling 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.







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


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.



4. As Administrator or root, edit the following file:



5. Search for UnconnectedAdminUpOrTestSwitchIF

You should see the following:


<filterName>UnconnectedAdminUpOrTestSwitchIF</filterName>

<parameterList>

<parameter>



<description>


</description>

Chapter 5134


<varValue>


<value>false</value>

</varValue>

</parameter>

6. Modify the bold false to true. Make sure to save your changes.







Disable ICMP Polling for ISDN, SLIP, and 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


<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


5. Create a backup copy of the following file prior to making anychanges.




7. Look for the following text:



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








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.


<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">



















Chapter 5138


<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:





<!-- 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>



<description>


</description>

<varValue>



</varValue>

</parameter>

<parameter>



Chapter 5 139


<description>


</description>

<varValue>



</varValue>

</parameter>

<parameter>

<name>hsrpEnable</name>


<description>

Enable/Disable polling of HSRP Group. If the

router/interface does not have hsrp enabled then setting

this parameter to true does nothing.

</description>

<varValue>



</varValue>

</parameter>

</parameterList>





<!-- Uncomment this class specification to use the APANoPollNodes

filter. Users should edit the APANoPollNodes.xml

file to specify what nodes are in the filter.<classSpecifications>

Chapter 5140



<filterName>APANoPollNodes</filterName>

<parameterList>

<parameter>

<name>enable</name>

<title>Enable config poll for device</title>

<description>

Enable/Disable config poll of a device

</description>

<varValue>



</varValue>

</parameter>

</parameterList>


</classSpecifications>









Chapter 5 141


Disable APA from Using ICMP to Poll 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:


• Windows:%OV_CONF%\nnmet\nnmet\topology\filter\TopoFilters.xml

• UNIX: $OV_CONF/nnmet/topology/filter/TopoFilters.xml

2. As Administrator or root, edit the TopoFilters.xml file.


<addressAssertion name="NoPingAddresses" title="No Ping Addresses"description="A

ddresses which should not be pinged">

<operator oper="OR">

<attribute>

<IPAddress>

<IPv4>

<address>15.2.112.22</address>

/IPv4>

</IPAddress>

</attribute>

<attribute>

<IPAddress>

<IPv4>

<address>15.2.119.52</address>

</IPv4>

</IPAddress>

</attribute>

<attribute>

Chapter 5142


<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


</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.






<!-- 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>



<description>


</description>

<varValue>



</varValue>

Chapter 5144


</parameter>

</parameterList>










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


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


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


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


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


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


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


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


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


• 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


%SYS-5-MOD_NORESPONSE OV_Syslog_Card_Failure

%SYS-5-MOD_OK OV_Syslog_Card_Online

%SYS-5-MOD_REMOVE OV_Syslog_Card_Removed

%SYS-5-MOD_INSERT OV_Syslog_Card_Inserted

%SYS-5-MOD_RESET OV_Syslog_Card_Reset

%SYS-3-MOD_FAIL OV_Syslog_Card_Failure

%SYS-3-MOD_FAILREASON OV_Syslog_Card_Failure

%SYS-3-MOD_CFGMISMATCH1 OV_Syslog_Card_Config_Mismatch




%PAGP-5-PORTTOSPT OV_Syslog_PAGP_JoinedBridgePort

%PAGP-5-PORTFROMSPT OV_Syslog_PAGP_LeftBridgePort

%DTP-3-TRUNKPORTFAIL OV_Syslog_Trunk_Port_Fail

%DTP-3-NONTRUNKPORTFAIL OV_Syslog_Trunk_NonTrunkPort_Fail

%DTP-5-TRUNKPORTON OV_Syslog_Trunk_Port_On

%DTP-5-TRUNKPORTCHG OV_Syslog_Trunk_Port_Change

%OSPF (all other OSPF messages) OV_Syslog_OSPF_Default_Message

%STANDBY (all other HSRP messages) OV_Syslog_HSRP_Default_Message

%PAGP (all other PAGP messages) OV_Syslog_PAGP_Default_Message

%SYS-n-MOD (all other Cisco 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)


Chapter 6158


%CDP OV_Syslog_CDP_Default_Message

%BGP OV_Syslog_BGP_Default_Message

Table 6-1 Syslog Trap Mappings (Continued)


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


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


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


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


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


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:


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:


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


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.


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.




Chapter 6166


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


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


8. To enable the MSI on the OVO agent coexisting on the NNMmanagement station, do the following:


b. Click Actions:Node ->Modify.

c. From the Modify Node window, click [Advanced Options].

d. From the Node Advanced Options window, check Enable 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:


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:


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


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.


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.



Chapter 6170



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


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


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


Figure 6-4 Syslog Trap Mapping Configuration Dialog

Chapter 6 175


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


• 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


Figure 6-6 Syslog to NNM Template Conditions

Chapter 6178


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 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



Chapter 6180


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



Chapter 6 181


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


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


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


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


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)


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


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


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


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)


Chapter 6188


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


• 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


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


• “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


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


(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


(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


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.



• Count

• Window Period

Chapter 7204


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.



• Count

• Window Period

Chapter 7 205


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.



• Count

Chapter 7206


• 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




• 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



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


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.


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


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.


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


• 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.



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.


The suppressed alarms can be viewed from the alarm browser bydouble-clicking the root cause syslog Board Down alarm.



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


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.


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.



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


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.


The suppressed alarms can be viewed from the alarm browser bydouble-clicking the root cause APA Board Down alarm.



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.


Chapter 7 217



2. A Board Down event is generated and forwarded to NNM.

3. The board ID is extracted from the event and the node ID 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.


The suppressed alarms can be viewed from the alarm browser bydouble-clicking the root cause APA Board Down alarm.



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


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


%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



TriggertoAPA


Chapter 7 221


%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


%STANDBY-6-STATECHANGE:Standby: [dec]: [chars] stateStandby -> Active




TriggertoAPA


Chapter 7222




%STANDBY-6-STATECHANGE:Standby: [dec]: [chars] stateStandby -> Init


%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



TriggertoAPA


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.


Chapter 7224


The suppressed OSPF Adjacency Change events can be viewed from theStatus Alarms Browser by double-clicking the root cause APA alarm.



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.


The suppressed HSRP State Change events can be viewed from theStatus Alarms Browser by double-clicking the root cause APA alarm.



Restart-Type Events with APA Node Status Alarms

Correlates Cold Start/Warm Start events and syslog RELOAD/RESTARTevents with APA Node status alarms.

Chapter 7 225


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.


The suppressed events can be viewed from the Status Alarms Browser bydouble-clicking the root cause APA alarm.



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.


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


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.


The suppressed events can be viewed from the Status Alarms Browser bydouble-clicking the APA Aggregrated Port alarm.



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.


Chapter 7228


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.


The suppressed events can be viewed from the Status Alarms Browser bydouble-clicking the APA Aggregated Port alarm.



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


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


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


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


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


— 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


• 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 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


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


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 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


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 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


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


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


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


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


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


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


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


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


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 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


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


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


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


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


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


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


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


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:



Chapter 10278


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


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


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


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


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


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


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


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


• 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


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


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


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


• 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


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


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:


• 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



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


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


— 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.


Appendix C308


5. As Administrator or root, type ovstart ovas.


7. As Administrator or root, type ovstart ovet_poll.


Practical Examples

The following examples depict some actual connectivity problems 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


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


::+++++++++++++++++ NMInterface ++++++++++++++

Appendix C310


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


+++++++++++++++++ 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


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


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


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


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


• 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.


3. As Administrator or root, type ovstop ovet_poll.


5. As Administrator or root, type ovstart ovas.


7. As Administrator or root, type ovstart ovet_poll.


• To make sure the Dynamic Views contain all of your changes, 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 Addresses
IPv6 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


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


329

Index

HSRP pollingdisabling, 128enabling, 128

HSRP State Change event, 202, 225HSRP State Change events

listening for, 225viewing suppressed, 225

IICMP polling


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


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

Documents

Using Extended Topology